Scratchbox2 segfaults on Ubuntu 11.10 and 64-bits.

[Svartalf]

Doesn't matter what I do, it comes back with the following while attempting to use old sandboxes or start up new ones:

frank@zaphod:~$ sb2
/usr/bin/sb2: line 1137: 7597 Segmentation fault cat >> $SBOX_SESSION_DIR/exec_config.lua <<END

conf_cputransparency_has_argv0_flag=$conf_cputransparency_has_argv0_flag
conf_cputransparency_qemu_has_env_control_flags=$conf_cputransparency_qemu_has_env_control_flags
conf_cputransparency_qemu_has_libattr_hack_flag=$conf_cputransparency_qemu_has_libattr_hack_flag
conf_cputransparency_qemu_ld_library_path="$conf_cputransparency_qemu_ld_library_path"
conf_cputransparency_qemu_ld_preload="$conf_cputransparency_qemu_ld_preload"
conf_cputransparency_qemu_argv=$conf_cputransparency_qemu_argv
conf_cputransparency_qemu_env=$conf_cputransparency_qemu_env
END

/usr/bin/sb2: line 175: 7598 Segmentation fault /bin/mkdir -p $SBOX_SESSION_DIR/argvmods
/usr/bin/sb2: line 177: /tmp/sb2-frank-20120319-213002.oyxHEV/argvmods/argvmods_misc.lua: No such file or directory
sb2: Error: Failed to create 'argvmods_misc' rules
frank@zaphod:~$

Tried to use upstream on a VM to no avail.

Release Info:

frank@zaphod:~$ lsb_release -rd
Description: Ubuntu 11.10
Release: 11.10

Version Info:

frank@zaphod:~$ apt-cache policy scratchbox2
scratchbox2:
  Installed: 2.2.3-1debian1
  Candidate: 2.2.3-1debian1
  Version table:
 *** 2.2.3-1debian1 0
        500 http://us.archive.ubuntu.com/ubuntu/ oneiric/universe amd64 Packages
        100 /var/lib/dpkg/status

This tool is used by the Tizen project, Plugdev, Non-native Raspberry PI dev, along with many others (Incl. my indie game porting endeavors (See: Caster3D and Cortex Command)).

[Svartalf (frank-earlconsult)]

Looks like there's several behaviors lurking within the codebase itself. If you have "too old" a dist, it is the source of the issues in question. Need to look into the behavior further, but it looks like it munges the dist's code execution with the host- which wasn't what was expected for sb2-init setup of things. I'd have thought that it'd be sandboxing with the rules out of the gate, which would've prevented most of this behavior.

If you want to close the issue...go for it. I've a workaround for things here in using a minimal "rootstrap" of the host's distribution version, sufficent to handle providing perl/python/etc. for the environment. I'll take up the issue with upstream after I have a solid handle on what it thinks it's doing and possibly with a patchset for mainline and the development branches.

[Svartalf (frank-earlconsult)]

As an addendum, I'm finding that while it's building things MOSTLY correctly, it isn't configuring the sandbox correctly with 64-bits. I'm no longer getting segfaults, but it's getting seriously confused and it needs a 32-bit dist set for things. Looks like there's some re-work done because it's screwing this up with Debian as well (something tells me that the upstream devs aren't using this QUITE like I am. (Game dev- porting Indie and other titles to Linux and then making it work on 32/64-bit and diverse non-X86 platforms...))

Even though I'm not a dev for Ubuntu, I'll ferret out what needs to be done- mainly in keeping with the fact that it's clear that I'm on the edge here with this and I rely on this for much more than the game porting.

I'll keep updating this issue- please keep the issue going for now...

[Svartalf (frank-earlconsult)]

Well, looking at their scripting for sb2, the workaround for the second, related issue is for when you're doing a 64-bit compilation to use a 64-bit dist set and adjust the toolset to have a symlink to the 64-bit ld-linux so file up at the /lib level. At that point it finds the right things and does the right things. There needs to be a re-work, but sadly there's no ready made tools to help so it may be a bit before I or someone else come up with a better answer.