Re: Fwd: Re: [Fxruby-users] random crashes with FXTable

[Emmanuel T. <emm...@wa...>]

Hello,

thank you VERY MUCH for the quick answer!!!

On Monday 21 of July 2003 17:08, Lyle Johnson wrote:
> Emmanuel Touzery wrote:
> >     This bug really blocks me, as the application is not usable in this
> > state; I was wondering if you could just tell me approximately when you
> > hope to fix it (days, weeks, months?).
>
> I am still trying to find a way to *consistently* reproduce the crash
> under Linux. Unlike your experience, the program doesn't crash when I
> simply try to load the glossary file (lyle-good.glo). I did get it to
> crash once, I think in the Bibliography dialog box, but haven't been
> able to do that again.

oh.. i guess it must be a combination of glibc, ruby, etc... my system is a=
=20
mandrake 8.0, kernel 2.4.3-20mdk, glibc 2.2.2-4mdk.

but for me it's quite amazing, i tried to reduce the program to reproduce t=
he=20
crash (i hoped to port it to C++ to see if it's a FOX problem maybe), i=20
started by trying to reduce the input file that creates the crash=20
(good-lyle.glo). as a result, i could remove maybe one or two lines out of=
=20
200 or so!  removing any single of the others, and the crash (at startup)=20
goes away (i didn't try to reorder lines). crashes on use under windows=20
happen at one point or another, always. i didn't use it long enough under=20
linux to know.

what is your system? I have access to SuSE linux boxes at work (a bit old=20
versions i'm afraid). if (big luck but ok) i would have access to the same=
=20
version of linux than you, i could try to make it reproduceable there.. (i=
=20
assume you're on x86).
if you can debug on windows, too (i assume), which windows? i have access t=
o=20
98/XP/2000 boxes. i can try to make it crash for sure on those too..

(i'll try to generate dummy .glo files until i get something)

> >     I tried with ruby 1.8 and the problems persist. I tried to fix it
> > myself, but it seems to be some kind of memory corruption problem, and
> > without knowledge of the source, i'm not getting anywhere. I would try =
to
> > reduce the source code related to the bug, but it's so easy to reproduc=
e,
> > and the code is generally so simple, that i guess it wouldn't help (only
> > maybe if i reduce it a lot and try to port it to FOX/C++ to see if it's=
 a
> > FOX bug maybe.. but it would take me forever...).
>
> As already noted, it's not so easy to reproduce (for me anyways ;) I
> agree with you that it's probably some kind of memory corruption
> problem; most of these difficult-to-reproduce bugs end up being related
> to interactions with Ruby's garbage collector. As a workaround, you
> might simply try disabling garbage collection altogether by adding the
> line:
>
>      GC.disable
>
> at the beginning of the program.

thank you very much!
i agree with you it should be related to the ruby garbage collector.. AND i=
n=20
my case, the systematic crash under linux goes away when i add GC.disable a=
t=20
the start of the program. i'll try under windows to see if my other crashes=
=20
go away, tomorrow...

thank you, it seems that's the workaround i was looking for!

i'll still try to reproduce the bug 100% under windows.

emmanuel.
=2D-=20
"Droit devant soi, on ne peut pas aller bien loin"
	- Le petit prince, Antoine de Saint Exup=E9ry