QEMU (on Haiku) doesn't work anymore

[aldeck]

QEMU (on Haiku) won't run an haiku image i just built (and tested ok with qemu on a linux box). It used to work flawlessly on a mid july rev.

It fails with the following output on stdout:

Abort
Killed (by death)

No userland crash or kdl, nothing in the syslog either.

Haiku hrev38635, qemu 0.11.1 from ​http://www.bebits.com/app/4208

[aldeck]

I narrowed it between hrev38152 (OK) and hrev38209 (Not OK) using prebuilt images. I will now use sources to get further.

[aldeck]

hrev38162 should be the culprit!

hrev38161 OK, hrev38162 (lots of changes but doesn't build due to time preflet missing localtime.h), hrev38163 Not OK

[aldeck]

Michael might have an idea too :) Btw Michael, could you provide the sources of your qemu port? Or even nicer would be to publish your patch(es) on haiku-ports. Regards.

[zooey]

The problem is that qemu relies on being able to enlarge one of the three areas it has created. That used to work, but with the adjustments that were done to libroot, more areas are being created (caused by the dynamic loading of libroot-addon-icu.so) immediately following the qemu-areas. So when qemu tries to resize one of its own areas, it can't and then aborts.

Without having the qemu source, I can only speculate on why qemu doesn't create the area with the correct size right from the start. If that can't be done, another possibility would be to trigger loading of libroot-addon-icu.so (e.g. by invoking tzset()) before creating its own areas.

[bonefish]

Replying to zooey:

Without having the qemu source, I can only speculate on why qemu doesn't create the area with the correct size right from the start. If that can't be done, another possibility would be to trigger loading of libroot-addon-icu.so (e.g. by invoking tzset()) before creating its own areas.

That theory can be easily tested without modifying qemu. Just write a mini-library that invokes tzset() in its static initialization and add it to LD_PRELOAD when starting qemu.

[zooey]

Replying to bonefish:

Replying to zooey:

Without having the qemu source, I can only speculate on why qemu doesn't create the area with the correct size right from the start. If that can't be done, another possibility would be to trigger loading of libroot-addon-icu.so (e.g. by invoking tzset()) before creating its own areas.

That theory can be easily tested without modifying qemu. Just write a mini-library that invokes tzset() in its static initialization and add it to LD_PRELOAD when starting qemu.

Yep, I already tested with LD_PRELOAD=libroot-addon-icu.so and that works. So we should be able to fix the issue in qemu easily, one way or the other. I'd rather refrain from hacking around the problem by changing how libroot loads its addon.

[tonestone57]

Michael posted a link to his QEMU 10.4 diff in the mailing list post below:

​http://www.freelists.org/post/haiku-development/Adding-some-new-OptionalPackages,7

That should allow someone to get QEMU working on Haiku once more.

[umccullough]

In addition to the "Abort Killed (by death)" issue, QEMU also links to the libssl.so.0.9.8 and libcrypto.so.0.9.8 which are no longer included with Haiku. Haiku's SSL has been updated to 1.0.0 now and I had to create symlinks for the older lib versions in order to get it working.

That was when I hit the bigger problem and discovered this was a known-issue. :(

[pulkomandy]

Current qemu package does not crash anymore.