On Saturday 01 September 2007 05:44, Sergey Plis wrote: > For the last 2-3 days I am chasing a very nasty bug. I am not sure > what causes it. It involves a mixture of gsl, floating point > operations and memory allocation. Basically, if I allocate memory and > write to it and then free it just before a call to gsl ode solver I > get segmentation fault. It I do not do it then I get error 0037 > (floating point error) though later in one of the next loops. In any > case I am not sure if I found the bug but here is what I found. Start > bigforth and do: > > also dos > 100 allocate throw dup 1 swap ! free throw
I see that problem, too. Probably a change in the kernel API that now checks something it didn't check before. > I have tried the trick at three different systems and two different > versions of bigforth. All of them consistently give the following: > > *** glibc detected *** bigforth: munmap_chunk(): invalid pointer: > 0x1008cca0 *** > ======= Backtrace: ========= > /lib/tls/i686/cmov/libc.so.6(cfree+0x1bb)[0xb7e6df5b] > [0x1007c832] > ======= Memory map: ======== > and so on > > However, all those were 32bit systems. When I have tried it at a > 64bit machine everything worked smoothly. I can reproduce it on a 64 bit machine. > Unfortunately the machine is not usable to me since bigforth does not > bind libraries (64bit) there: > > liblapack.so.3 Library not found! You need to install the 32 bit version of the library. This is sometimes a bit complicated to achieve. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
pgp2DLWyqUvLw.pgp
Description: PGP signature
