Re: More toolchain issues

[Frank Wille <frank%phoenix.owl.de@localhost>]

John Klos wrote:

On 16.09.09 18:58:06 you wrote:

> scan_engine.cc: In function 'bool
> get_pcap_result(UltraScanInfo*, timeval*)': scan_engine.cc:3937: internal
> compiler error: Segmentation fault
> [...]
> After about two and a half minutes of CPU time and after growing to more 
> than 60 megs, cc1plus stops and complains.

When I compiled pkgsrc/net/nmap on my A3000/CSPPC-060/135MB with the
5.0.1 standard jemalloc clib installed, it compiled scan_engine.cc in 7
minutes. But there was a total system crash six files later. Unfortunately I
didn't observe that, but just saw a blank ECS screen and constantly bright
HD-LEDs when I returned (compilation ran on a CV64 screen before).

I had exactly the same crash a few days ago, on another compilation test!

After restart the system did an fsck and immediately rebooted after that.
The next boot was successful and I could continue to work.

I deleted scan_engine.cc and tried to reproduce the crash, but without
success. This time nmap was compiled and installed without problem!


> Between this and the last 
> problem, I'm confused - isn't our unlimited datasize 128 megs?

Yes, it is.


> Why are these dying after reaching 64 megs?

A good question. I agree with you that there is something wrong, perhaps
caused by switching to jemalloc or the latest modifications in pmap.c?

I can indeed reproduce the 64 MB problem. After installing nmap I ran a test
with "nmap -A -T4" on my router, and nmap segfaulted after a few seconds.
gdb showed an invalid access to 0x840400, an address which looks ok to me.
The crash location is inside a jemalloc function again (called by free(),
calloc()).

When I repeated the test I observed that the segfault indeed happened when
the "SIZE" in "top" reaches 64M.

This test is 100% repeatable.


> I've tried Frank's libc with phk-allocator in place of jemalloc, and the 
> compilation (at least of scan_engine.o) is still running after two hours 
> (60 MHz m68060), and the size went above 64 megs (up to 69, at least).

Did it finish? Usually it shouldn't take more than 7 minutes. So there is
also a problem here. Maybe the problem is not jemalloc, but it shows up more
drastically in je-malloc than in phk-malloc.


> So what's broken with jemalloc that doesn't allow more than 64 megs to be 
> used? Is this an m68k problem, or are different allocators used by 
> different ports?

AFAIK all ports switched to jemalloc. The switch was not done by port, but
globally in the libc Makefile.


> This'll be good to get fixed before resuming a bulk package build...

Indeed. We should find out if such a problem can be reproduced on other 68k
architectures. Unfortunately I have only Amigas here.

BTW, Michael Hitch just switched port-amiga from its owm pmap.c to m68k's
pmap-motorola.c, 5 days ago. We could try if it changes anything.


-- 
Frank Wille