From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.14-5.0 i586)
i have a machine that was freshly installed with the wolverine beta. i
downloaded the source code for OpenH323 code available here:
the two packages required are:
i can compile the pwlib files ok. but when i try and compile the openh323
package, i get one of two different problems. the first time i tried it, i
simply got a segmetation fault, and it crashed. i tried again to get the
exact error message and now a slightly different sequence of events occured
( i had not rebooted since trying the first time ).
it was cranking away trying to compile the h245_1.cxx file, and spending a
great deal of time swapping. eventually, i heard the drive stop making
noises, but the make process still looked like it was running. i tried to
do a top to see what was going on, but top hung. i mean, really hung.
it's been over 30 minutes now, and still nothing. this was all done while
being logged in remotely. so i logged into the machine locally, but again
the top command hung. in fact, so did 'ps ax', 'ps x' and 'ps a'. the 'ps
a' one is weird, as that shouldn't have even found the g++ process. both
the 'ps ax' and 'ps x' commands would show a bunch of processes, show one
g++ process, then hang after that. even trying a 'memusage top' caused
things to hang. and i do mean hang. i can login, i can run vi, run
iptables, run all sorts of things, and the existing background processes
are all intact afaict.
i tried to keep an eye on memusage while this was going on, and found that
it seemed to hang around all the RAM being used ( 64MB total ) and about
60-70 MBs of swap being used ( 128MB total ).
Steps to Reproduce:
1. get and compile pwlib in ~/pwlib
2. export LD_LIBRARY_PATH=~/pwlib/lib
3. get and compile openh323
4. problem occurs in h245_1.cxx
Actual Results: once, seg. fault
once, hang, taking parts of the system down ( can't top, ps or w )
Expected Results: built the openh323 library... ;-)
this machine is no power house, its a p-100 ( normal old pentium ) with
64MB or real RAM and 128MB of swap.
i actually thing that this bug is not really a gcc bug at all, but a kernel
swap/vm issue. after compiling it again and keeping a close eye on it, i saw
the vm usage run way up over 100MB. as i only have 128MB of swap ( 64MB RAM ),
i presumed that it was running out of swap and crashing the whole machine. so,
i created two new swap files of 128MB each and recompiled, and it was able to
compile, up until it ran into a real, easily reproducable, gcc bug, which i have
submitted in bug #31168.
*** This bug has been marked as a duplicate of 31168 ***