--- Nicolas Cannasse <[EMAIL PROTECTED]> wrote:
> Joe Wilson a écrit :
> > --- Nicolas Cannasse <[EMAIL PROTECTED]> wrote:
> >>> I was unable to find the cause of the gcc 4.1.1 -O[123] build crash in
> >>> part due to memory explosion. The neko process was using over 2G of swap
> >>> space on my 512M machine. I wonder if this was due to a failure of
> >>> Boehm GC due to a bad interaction with a certain compiler optimization
> >>> in this specific version of gcc.
> >> I think that's due to an infinite loop that's causing too much memory
> >> allocation. It doesn't happen because of the GC since it can't be
> >> reproduced by just recompiling Neko with other GCC/-O flags.
> >
> > Neko 1.6.0 compiled with gcc 4.1.1 -O[123] crashes.
> >
> > However, Neko compiled with gcc 4.1.1 -O[123] -fno-unit-at-a-time is okay.
> >
> > I don't know whether this is a bug in Neko, gcc, or libgc, but
> > could you please add -fno-unit-at-a-time to the Neko Makefile?
> > The gcc 4.1.1 compiler is used in many Linux distros, and it
> > would be nice if it built "out of the box" on those machines.
>
> I'm not sure that disabling no-unit-at-a-time would be a good idea,
> since it seems to improve several things :
> http://lwn.net/Articles/67176/
>
> I would be more interested to know which loop in the JIT cause the
> problem. Try to uncomment JIT_DEBUG in jit_x86.c
No new information. Same as before:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210283632 (LWP 4856)]
0xb7e9b82a in memcpy () from /lib/i686/libc.so.6
(gdb) where
#0 0xb7e9b82a in memcpy () from /lib/i686/libc.so.6
#1 0xb7f9663d in neko_module_jit (m=0x80a3f88) at vm/jit_x86.c:2616
#2 0xb7f93bc7 in neko_read_module (r=0xb7f92ef3 <neko_file_reader>,
p=0x807b038, loader=0x8060fc0) at vm/module.c:510
#3 0xb7f91034 in loader_loadmodule (mname=0x80617c0, vthis=0x8060fc0)
at vm/load.c:349
#4 0xb7f89229 in neko_val_callEx (vthis=0x8060fc0, f=0x805e960,
args=0xbfe39a4c, nargs=2, exc=0xbfe39a54) at vm/callback.c:76
#5 0x080493b4 in ?? ()
#6 0x08060fc0 in ?? ()
#7 0x0805e960 in ?? ()
#8 0xbfe39a4c in ?? ()
#9 0x00000002 in ?? ()
#10 0xbfe39a54 in ?? ()
#11 0xb7f9ea50 in ?? ()
#12 0xbfe39b94 in ?? ()
#13 0x00000005 in ?? ()
#14 0xb7e4045e in ?? () from /lib/i686/libc.so.6
#15 0xbfe39b98 in ?? ()
#16 0x00000000 in ?? ()
You can probably reproduce this segfault on any x86 2.6 Linux using
gcc 4.1.1 and either gc6.8 or gc-7.0.
I tried using valgrind to spot the problem, but it does not appear
to be compatible with the Boehm collector, which is what prompted me
to ask about a precise GC option.
____________________________________________________________________________________
Park yourself in front of a world of choices in alternative vehicles. Visit the
Yahoo! Auto Green Center.
http://autos.yahoo.com/green_center/
--
Neko : One VM to run them all
(http://nekovm.org)
