Opened 15 years ago
Closed 15 years ago
#4087 closed bug (fixed)
Building ZooLib ButtonMessage sample crashes Haiku when run under VirtualBox
Reported by: | MichaelCrawford | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | System/Kernel | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
ZooLib is a C++ cross-platform application framework. It is close to supporting Haiku, but I find that building it often crashes the system, when I run Haiku under VirtualBox on my Fedora 10 Xeon box.
Possibly this is actually a bug in VirtualBox; if I can I'll try running Haiku under KVM and VMware.
I have seen this problem with several different versions of both Haiku and of VirtualBox. Presently I'm using the GCC 2.95.3 build of Haiku hrev31471 and VirtualBox 3.0.0.
ZooLib's SourceForge project has both Subversion and CVS repositories. The Subversion code isn't building yet; I've been preparing a release from the older CVS code. To fetch the CVS sources:
$ cvs -z3 -d:pserver:anonymous@zoolib.cvs.sourceforge.net:/cvsroot/zoolib checkout -P zoolib
Delete or rename zoolib/src/platform/beos/TLS.h - it conflicts with the file of the same name that comes with Haiku.
cd into zoolib/samples/buttonmessage/buttonmessage_build_be and type "make".
After compiling a few files, either Haiku will freeze or VirtualBox will report that the guest has crashed. If you reboot Haiku and try the make again, gcc will report that some of the object files are in an unrecognized format.
Change History (19)
comment:1 by , 15 years ago
comment:2 by , 15 years ago
That Fedora 10 box has a 2.5 GHz Core 2 Quad Xeon e5420 on a Supermicro X7DWA-N motherboard. The board is socketed for two CPUs but I just have one installed presently. I'm using the x86_64 build of VirtualBox.
I will try it on my MacBook Pro this evening.
comment:3 by , 15 years ago
Here's what I get on real hardware (AMD Geode 500MHz, been running for 47 days 18 hours and still not crashed) with gcc2 and Haiku hrev30665:
~/develop/zoolib/samples/buttonmessage/buttonmessage_build_be> make g++ -I../../../samples/buttonmessage/buttonmessage_src -I./ -I../../../src/_deprecated -I../../../src/asset -I../../../src/compat -I../../../src/config -I../../../src/config_choices -I../../../src/file -I../../../src/foundation -I../../../src/graphics -I../../../src/net -I../../../src/platform/beos -I../../../src/platform/macos -I../../../src/platform/posix -I../../../src/platform/win32 -I../../../src/printing -I../../../src/stream -I../../../src/text -I../../../src/thread -I../../../src/uicore -I../../../src/uiextra -pipe -D_REENTRANT -g -DDEBUG -c ../../../samples/buttonmessage/buttonmessage_src/BMApp.cpp -o objects-debug/BMApp.o g++ -I../../../samples/buttonmessage/buttonmessage_src -I./ -I../../../src/_deprecated -I../../../src/asset -I../../../src/compat -I../../../src/config -I../../../src/config_choices -I../../../src/file -I../../../src/foundation -I../../../src/graphics -I../../../src/net -I../../../src/platform/beos -I../../../src/platform/macos -I../../../src/platform/posix -I../../../src/platform/win32 -I../../../src/printing -I../../../src/stream -I../../../src/text -I../../../src/thread -I../../../src/uicore -I../../../src/uiextra -pipe -D_REENTRANT -g -DDEBUG -c ../../../samples/buttonmessage/buttonmessage_src/BMButtonWindow.cpp -o objects-debug/BMButtonWindow.o g++ -I../../../samples/buttonmessage/buttonmessage_src -I./ -I../../../src/_deprecated -I../../../src/asset -I../../../src/compat -I../../../src/config -I../../../src/config_choices -I../../../src/file -I../../../src/foundation -I../../../src/graphics -I../../../src/net -I../../../src/platform/beos -I../../../src/platform/macos -I../../../src/platform/posix -I../../../src/platform/win32 -I../../../src/printing -I../../../src/stream -I../../../src/text -I../../../src/thread -I../../../src/uicore -I../../../src/uiextra -pipe -D_REENTRANT -g -DDEBUG -c ../../../samples/buttonmessage/buttonmessage_src/BMDisplayWindow.cpp -o objects-debug/BMDisplayWindow.o g++ -I../../../samples/buttonmessage/buttonmessage_src -I./ -I../../../src/_deprecated -I../../../src/asset -I../../../src/compat -I../../../src/config -I../../../src/config_choices -I../../../src/file -I../../../src/foundation -I../../../src/graphics -I../../../src/net -I../../../src/platform/beos -I../../../src/platform/macos -I../../../src/platform/posix -I../../../src/platform/win32 -I../../../src/printing -I../../../src/stream -I../../../src/text -I../../../src/thread -I../../../src/uicore -I../../../src/uiextra -pipe -D_REENTRANT -g -DDEBUG -c ../../../samples/buttonmessage/buttonmessage_src/BMMain.cpp -o objects-debug/BMMain.o g++ -I../../../samples/buttonmessage/buttonmessage_src -I./ -I../../../src/_deprecated -I../../../src/asset -I../../../src/compat -I../../../src/config -I../../../src/config_choices -I../../../src/file -I../../../src/foundation -I../../../src/graphics -I../../../src/net -I../../../src/platform/beos -I../../../src/platform/macos -I../../../src/platform/posix -I../../../src/platform/win32 -I../../../src/printing -I../../../src/stream -I../../../src/text -I../../../src/thread -I../../../src/uicore -I../../../src/uiextra -pipe -D_REENTRANT -g -DDEBUG -c ../../../samples/buttonmessage/buttonmessage_src/MessageButtonPane.cpp -o objects-debug/MessageButtonPane.o g++ -I../../../samples/buttonmessage/buttonmessage_src -I./ -I../../../src/_deprecated -I../../../src/asset -I../../../src/compat -I../../../src/config -I../../../src/config_choices -I../../../src/file -I../../../src/foundation -I../../../src/graphics -I../../../src/net -I../../../src/platform/beos -I../../../src/platform/macos -I../../../src/platform/posix -I../../../src/platform/win32 -I../../../src/printing -I../../../src/stream -I../../../src/text -I../../../src/thread -I../../../src/uicore -I../../../src/uiextra -pipe -D_REENTRANT -g -DDEBUG -c ../../../src/foundation/ZUnicode.cpp -o objects-debug/ZUnicode.o /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:326: explicit instantiation of `struct ZUnicode::Functions_CountCU_T<const long unsigned int *>' after /boot/home/develop/zoolib/src/foundation/ZUnicodePriv.h:58: explicit specialization here /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:327: explicit instantiation of `struct ZUnicode::Functions_CountCU_T<const __wchar_t *>' after /boot/home/develop/zoolib/src/foundation/ZUnicodePriv.h:71: explicit specialization here /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:328: explicit instantiation of `struct ZUnicode::Functions_CountCU_T<const char *>' after /boot/home/develop/zoolib/src/foundation/ZUnicodePriv.h:84: explicit specialization here /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:330: explicit instantiation of `struct ZUnicode::Functions_CountCU_T<long unsigned int *>' after /boot/home/develop/zoolib/src/foundation/ZUnicodePriv.h:97: explicit specialization here /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:331: explicit instantiation of `struct ZUnicode::Functions_CountCU_T<__wchar_t *>' after /boot/home/develop/zoolib/src/foundation/ZUnicodePriv.h:110: explicit specialization here /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:332: explicit instantiation of `struct ZUnicode::Functions_CountCU_T<char *>' after /boot/home/develop/zoolib/src/foundation/ZUnicodePriv.h:123: explicit specialization here /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:343: duplicate explicit instantiation of `struct ZUnicode::Functions_Count_T<const long unsigned int *>' /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:344: duplicate explicit instantiation of `struct ZUnicode::Functions_Count_T<const __wchar_t *>' /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:345: duplicate explicit instantiation of `struct ZUnicode::Functions_Count_T<const char *>' /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:347: duplicate explicit instantiation of `struct ZUnicode::Functions_Count_T<long unsigned int *>' /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:348: duplicate explicit instantiation of `struct ZUnicode::Functions_Count_T<__wchar_t *>' /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:349: duplicate explicit instantiation of `struct ZUnicode::Functions_Count_T<char *>' /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:360: duplicate explicit instantiation of `struct ZUnicode::Functions_Read_T<const long unsigned int *,long unsigned int>' /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:361: duplicate explicit instantiation of `struct ZUnicode::Functions_Read_T<const __wchar_t *,__wchar_t>' /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:362: duplicate explicit instantiation of `struct ZUnicode::Functions_Read_T<const char *,char>' /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:364: duplicate explicit instantiation of `struct ZUnicode::Functions_Read_T<long unsigned int *,long unsigned int>' /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:365: duplicate explicit instantiation of `struct ZUnicode::Functions_Read_T<__wchar_t *,__wchar_t>' /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:366: duplicate explicit instantiation of `struct ZUnicode::Functions_Read_T<char *,char>' /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:373: duplicate explicit instantiation of `struct ZUnicode::Functions_Write_T<long unsigned int *,long unsigned int>' /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:374: duplicate explicit instantiation of `struct ZUnicode::Functions_Write_T<__wchar_t *,__wchar_t>' /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:375: duplicate explicit instantiation of `struct ZUnicode::Functions_Write_T<char *,char>' /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:386: duplicate explicit instantiation of `struct ZUnicode::Functions_Convert_T<const long unsigned int *>' /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:387: duplicate explicit instantiation of `struct ZUnicode::Functions_Convert_T<const __wchar_t *>' /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:388: duplicate explicit instantiation of `struct ZUnicode::Functions_Convert_T<const char *>' /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:390: duplicate explicit instantiation of `struct ZUnicode::Functions_Convert_T<long unsigned int *>' /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:391: duplicate explicit instantiation of `struct ZUnicode::Functions_Convert_T<__wchar_t *>' /boot/home/develop/zoolib/src/foundation/ZUnicode.cpp:392: duplicate explicit instantiation of `struct ZUnicode::Functions_Convert_T<char *>' make: *** [objects-debug/ZUnicode.o] Error 1 ~/develop/zoolib/samples/buttonmessage/buttonmessage_build_be>
It errors out but didn't crash.
follow-up: 5 comment:4 by , 15 years ago
Crashes while compiling on VirtualBox are somewhat common from what I've heard. I've also had people tell me VBox crashes with guru meditation quite frequently while attempting to compile on it.
Often times, I've found that compiling the same software on real hardware yields no crash.
Not sure what to suggest though :(
comment:5 by , 15 years ago
Replying to umccullough:
Crashes while compiling on VirtualBox are somewhat common from what I've heard. I've also had people tell me VBox crashes with guru meditation quite frequently while attempting to compile on it.
Often times, I've found that compiling the same software on real hardware yields no crash.
I'm not convinced that this really is a VBox problem. It is known that compiling some projects will reset the system on real hardware. Like compiling GCC on GCC4 Haiku does trigger that sometimes, but I've also seen it by building Haiku itself. A system reset is essentially impossible to debug when you have no clue how to reproduce it or where to start from. If this problem is indeed the same problem as with the system resets, and there is a reproducible testcase as well as an environment where you can work from, this would be a great candidate to track down this issue.
Is there any information that VBox outputs that could be used as a starting point to debug this? I don't have a system around that would run VBox, so I can't test this myself right now.
comment:6 by , 15 years ago
scottmc, all those errors are some problem that GCC 2.95.3 has with tricky template code. I got it to build OK with GCC 4 - I just had to keep rebooting - but am still working on the 2.95.3 support.
mmlr, when I get the Guru Meditation dialog, it offers to keep the guest loaded so that it can be examined with debugging tools. But it also warns that doing so is difficult.
Back to you soon on my MacBook Pro testing.
comment:7 by , 15 years ago
It might be that ZooLib provides more of a stress-test than most sourcebases, because some of its source files are very long and involved.
The usual C++ practice is to put just one class in a source/header pair, but many of ZooLib's modules have dozens of classes in them, and lots of really nasty implementation code.
comment:8 by , 15 years ago
For reference, can you provide the configuration for the VM you're running this in, i.e. amount of RAM and such?
comment:9 by , 15 years ago
With VirtualBox 2.2.4 on a Core Duo (not Core 2 Duo) MacBook Pro running Mac OS X 10.5.7, Haiku hrev31471 GCC4 hung while building ButtonMessage, but hrev31471 GCC 2.95.3 didn't hang.
I only tried each build once.
The 2.95.3 compile didn't actually complete because of that problem with tricky templates. But I did "make -k" so it would compile all the other sources despite the failure.
I will try next with VirtualBox 3.0.0.
Sometimes Haiku crashes during boot in VirtualBox on my MacBook Pro, but I think that's a different bug.
comment:10 by , 15 years ago
With VirtualBox 3.0.0 on my MacBook Pro, hrev31471 GCC4 hung during the build both times I tried it.
hrev31471 didn't have any problems the first time I tried it, but the second time an alert appeared saying g++ had crashed, then when I dismissed the alert the build continued for about a second and then I got that Guru Meditation message saying the guest had crashed.
mmlr, on my Mac I have these configurations for my VirtualBox guests - I'll post the Linux configs in a little while:
hrev31471 GCC 2.95.3
OS Type: Other/Unknown Base Memory: 256 MB Processors: 1 Boot Order: Floppy, CD-ROM, Hard Disk VT-x/AMD-v: Enabled (But I'm not sure my Core Duo CPU actually has the feature) Nested Paging: Disabled Video Memory: 32 MB 3D Accelleration: Enabled Remote Display Server: Disabled Hard Disk: Haiku on IDE Primary Master (ie not SATA) Host Audio Driver: Core Audio Controller: ICH 97 Network: Intel Pro 1000 MT Desktop (NAT) Serial Ports: Disabled USB Device Filters: 0 (0 Active) Shared Folders: None
hrev31471 GCC 4
OS Type: Other/Unknown Base Memory: 256 MB Processors: 1 Boot Order: Floppy, CD-ROM, Hard Disk VT-x/AMD-v: Enabled (But I'm not sure my Core Duo CPU actually has the feature) Nested Paging: Disabled Video Memory: 6 MB 3D Accelleration: Disabled Remote Display Server: Disabled Hard Disk: Haiku on IDE Primary Master (ie not SATA) Host Audio Driver: Core Audio Controller: ICH 97 Network: Intel Pro 1000 MT Desktop (NAT) Serial Ports: Disabled USB Device Filters: 0 (0 Active) Shared Folders: None
My MacBook Pro is a 1.83 GHz first-generation model. It has a Core Duo CPU, not Core 2 Duo. It is just 32-bit, and I don't think that the CPU actually has Intel VT-x. My memory is hazy, but it seems to me that some early version of VirtualBox complained when I tried to boot a guest with VT-x enabled.
Back to you this evening on the Linux configs.
comment:12 by , 15 years ago
That's about what I expected. If you give the VM 512MB RAM to run with it'll work. While there certainly are bugs in VirtualBox as well, this really looks more like a problem with low memory situations on Haiku's side to me. I can reproduce your issue by compiling most anything in VBox with little enough memory, I'll try to wrap my head around it, but it's not really easy to find a point to start here.
comment:13 by , 15 years ago
mmlr, both of my Linux guests had 512 MB in my initial tests. I tried the GCC4 build just now with more memory. I got crashes with 1024 and 2048 MB, but with 4096 MB I was able to build several times with no crashes.
Note that the hrev31471 build is distributed with virtual memory disabled. I'll try enabling it and giving it lots of swap space in a little while.
If the problem is memory stress, it would make sense to write a test tool that just uses up lots of memory in a repeatible way.
Quite likely the problem Haiku has with the ZooLib build is that some of its source files are quite large and complex, so g++'s symbol tables would take up a lot of memory.
comment:14 by , 15 years ago
comment:15 by , 15 years ago
Can you please retest and confirm. I'd like to note on the bug report over at VirtualBox (http://www.virtualbox.org/ticket/3265) if this was a Haiku problem or not.
comment:16 by , 15 years ago
I haven't tried building ZooLib for a while, but I'll do so in the next day or so.
However, I've done a bunch of builds with the much-smaller Word Services SDK, generally using the latest nightly, and haven't had any trouble with it.
comment:17 by , 15 years ago
The bug seems to be fixed for me with the hrev34248 GCC4 Hybrid and VirtualBox 3.0.8.
The ButtonMessage sample build completed, and the built program ran correctly with 512 MB and 256 MB of memory. With 128 MB the compiler ran out of memory, but it did the right thing by printing a diagnostic then aborting.
I haven't tried enabling virtual memory. There's not a lot of free space on the nightly image files. If you'd like me to try it with VM, I could copy the install over to a larger disk image.
Good Work! I can't imagine how this one had to be tracked down.
This will make all my ZooLib work a lot more pleasant. :-D
comment:18 by , 15 years ago
I forgot to mention... the ButtonMessage sample is a really basic "Hello, World" type of program. A more subtle test would be to compile something really complex, that had some really large and complex C++ classes in it, and then to verify that the built program ran correctly.
comment:19 by , 15 years ago
Component: | - General → System/Kernel |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Version: | R1/pre-alpha1 → R1/Development |
Thanks for the note. Please reopen if you find a new example :-)
The crash also occurs with the GCC4 build of hrev31471.