Can't screenshoot Web+ under libroot_debug.so

[humdinger]

This is hrev46754.

When I run Web+ with LD_PRELOAD=/system/lib/x86/libroot_debug.so /system/apps/WebPositive to get more useful backtraces in case of crashes, I can't take a screenshot when the Web+ window has focus. Something appears to eat my PRINT keystroke.

Not sure if it's a Web+ thing or gcc4 compiled apps in general. Couldn't find another gcc4 app quickly for comparison...

[pulkomandy]

When trying to do this from terminal:

runtime_loader: /boot/system/lib/libstdc++.r4.so: Could not resolve symbol '__ti9exception'
resolve symbol "__ti9exception" returned: -2147478780
runtime_loader: /boot/system/lib/libstdc++.r4.so: Troubles relocating: Symbol not found

What happens is the LD_PRELOAD is inherited to child processes. In this case, it seems the "Screenshot" app ends up being run with the gcc4 libroot_debug loaded, so it fails to run. We may want to at least catch the error and display the error message in an alert.

This happens in kits/interface/Window.cpp , and Screenshot is run using be_roster->Launch() by MIME signature. There is no error checking on the return value.

One level deeper, I don't know if be_roster->Launch() should inherit the LD_PRELOAD value from the environment.

[bonefish]

Replying to pulkomandy:

What happens is the LD_PRELOAD is inherited to child processes. In this case, it seems the "Screenshot" app ends up being run with the gcc4 libroot_debug loaded, so it fails to run.

libroot_debug is just an alternative libroot. Besides that a program might run into an assertion or other debug check in case of certain issues, it should just work the same way. I suppose the exception type info symbol should live in libgcc and thus libroot, so it should also live in libroot_debug. I checked on a gcc4h image and both (gcc 2) libroot and libroot_debug do indeed export the symbol.

We may want to at least catch the error and display the error message in an alert.

That would certainly be good.

One level deeper, I don't know if be_roster->Launch() should inherit the LD_PRELOAD value from the environment.

Since there's no environment parameter, it inherits the environment of the current process. I don't think filtering the environment is generally desirable. The caller could instead use FindApp() and then launch_image() manually. Obviously we could also add a Launch() version with an environment parameter.

[pulkomandy]

Replying to bonefish:

Replying to pulkomandy:

What happens is the LD_PRELOAD is inherited to child processes. In this case, it seems the "Screenshot" app ends up being run with the gcc4 libroot_debug loaded, so it fails to run.

libroot_debug is just an alternative libroot. Besides that a program might run into an assertion or other debug check in case of certain issues, it should just work the same way. I suppose the exception type info symbol should live in libgcc and thus libroot, so it should also live in libroot_debug. I checked on a gcc4h image and both (gcc 2) libroot and libroot_debug do indeed export the symbol.

Yes, that's fine. The problem is we end up running the gcc2-compiled Screenshot with the gcc4 version of libroot_debug preloaded. I had this problem in other cases when trying to debug an executable that was run by a shell script (for example, libtool sometimes generates such things to make it possible to run an application without installing the libs it depends on and that are built in the same project). In this case, it's hard to set LD_PRELOAD for the executable, without also setting it for the shell interpreter that's run first.

I don't know how we could handle all these cases, anyway. For this one, warning the user that running Screenshot failed may be enough.

[bonefish]

Replying to pulkomandy:

Yes, that's fine. The problem is we end up running the gcc2-compiled Screenshot with the gcc4 version of libroot_debug preloaded.

OK, I see. I guess the runtime loader could just unload any preloaded images that don't match the application ABI.

I had this problem in other cases when trying to debug an executable that was run by a shell script (for example, libtool sometimes generates such things to make it possible to run an application without installing the libs it depends on and that are built in the same project). In this case, it's hard to set LD_PRELOAD for the executable, without also setting it for the shell interpreter that's run first.

You could create a lib directory alongside the executable to run and symlink libroot_debug as libroot there.

[humdinger]

Replying to pulkomandy:

When trying to do this from terminal:

runtime_loader: /boot/system/lib/libstdc++.r4.so: Could not resolve symbol '__ti9exception'
resolve symbol "__ti9exception" returned: -2147478780
runtime_loader: /boot/system/lib/libstdc++.r4.so: Troubles relocating: Symbol not found

This now results in:

runtime_loader: /boot/system/bin/screenshot: Could not resolve symbol '__ti12BApplication'
resolve symbol "__ti12BApplication" returned: -2147478780
runtime_loader: /boot/system/bin/screenshot: Troubles relocating: Symbol not found