fxruby-users

Re: [Fxruby-users] Segfaults

[<ly...@kn...>]

On Sun, 04 Apr 2004 10:22:47 +0200, Gilles Filippini
<gil...@fr...> wrote :

> It takes about 60 iterations on may box. But this problems may eventualy 
> be unrelated to FXRuby:
> 
> - the segfault occurs without any Ruby msg. It's a brutal segfault:
> ...
> count = 58
> count = 59
> Erreur de segmentation
> maison:~/devel/bug$
> 
> - I've run the very same test case using valgrind and it's gone as far 
> as 6000+ before I stop it.
> 
> Well... I don't know where to look now :/

Is there any possibility at all that some of this machine's memory (RAM) is
going bad?

For what it's worth, I did go back and rebuild FXRuby-1.0.28 from the
sources and ran the test case for several thousand iterations before finally
killing it. So I'm fairly sure there is some other problem afoot.

Re: [Fxruby-users] Segfaults

[jeroen <je...@fo...>]

On Monday 05 April 2004 09:48 am, ly...@kn... wrote:
> On Sun, 04 Apr 2004 10:22:47 +0200, Gilles Filippini
>
> <gil...@fr...> wrote :
> > It takes about 60 iterations on may box. But this problems may eventualy
> > be unrelated to FXRuby:
> >
> > - the segfault occurs without any Ruby msg. It's a brutal segfault:
> > ...
> > count = 58
> > count = 59
> > Erreur de segmentation
> > maison:~/devel/bug$
> >
> > - I've run the very same test case using valgrind and it's gone as far
> > as 6000+ before I stop it.
> >
> > Well... I don't know where to look now :/
>
> Is there any possibility at all that some of this machine's memory (RAM) is
> going bad?

Extremely unlikely.  Even if it were the case, your process wouldn't get the
same physical pages to run in each time it starts.

It *could* be memory related, however.  The fact that you can run under
valgrind (which subsumes malloc() and free() with its own functions), is
a big clue.  


> For what it's worth, I did go back and rebuild FXRuby-1.0.28 from the
> sources and ran the test case for several thousand iterations before
> finally killing it. So I'm fairly sure there is some other problem afoot.

Let me know if it is in FOX or specific to ruby bindings of FOX; if it
is in FOX then I'll try and fix it quickly.  By the way, we're at patchlevel
1.0.51 with the stable version, and since the API is the same I suggest
people run against that instead of the 1.0.28 version.


	Regards!

		- Jeroen


-- 
+----------------------------------------------------------------------------+
| Copyright (C) 23:50 12/11/2003 Jeroen van der Zijp.   All Rights Reserved. |
+----------------------------------------------------------------------------+

Re: [Fxruby-users] Segfaults

[Gilles F. <gil...@fr...>]

ly...@kn... a =E9crit :
> On Sun, 04 Apr 2004 10:22:47 +0200, Gilles Filippini
> <gil...@fr...> wrote :
>=20
>=20
>>It takes about 60 iterations on may box. But this problems may eventual=
y=20
>>be unrelated to FXRuby:
>>
>>- the segfault occurs without any Ruby msg. It's a brutal segfault:
>>...
>>count =3D 58
>>count =3D 59
>>Erreur de segmentation
>>maison:~/devel/bug$
>>
>>- I've run the very same test case using valgrind and it's gone as far=20
>>as 6000+ before I stop it.
>>
>>Well... I don't know where to look now :/
>=20
>=20
> Is there any possibility at all that some of this machine's memory (RAM=
) is
> going bad?

I don't think so: the fact is that it segfaults precisely at count =3D 59=
.=20
Would it be memory related I guess its behavior would be much less=20
predictible.
BTW I have other processes running (Apache, MySQL, Oracle, Mozilla,=20
aMule, distributed.net, ...) with an uptime of about one week and I=20
didn't notice anything weird.

> For what it's worth, I did go back and rebuild FXRuby-1.0.28 from the
> sources and ran the test case for several thousand iterations before fi=
nally
> killing it. So I'm fairly sure there is some other problem afoot.

I've made another test with GC disabled: no segfault (updated the=20
sourceforge bug page).
I'll try to run it tomorrow at work on another machine.
Stay tuned...

_gilles.

Re: [Fxruby-users] Segfaults

[Lyle J. <ly...@kn...>]

On Apr 5, 2004, at 10:48 AM, Gilles Filippini wrote:

> I don't think so: the fact is that it segfaults precisely at count = 
> 59. Would it be memory related I guess its behavior would be much less 
> predictible.

Yes, on reflection I think you're right that it wouldn't be so easily 
reproducible on your machine if there were some memory fault.

> BTW I have other processes running (Apache, MySQL, Oracle, Mozilla, 
> aMule, distributed.net, ...) with an uptime of about one week and I 
> didn't notice anything weird.

OK.

> I've made another test with GC disabled: no segfault (updated the 
> sourceforge bug page).
> I'll try to run it tomorrow at work on another machine.
> Stay tuned...

OK. I saw the bug reports, but haven't had a chance to run the table 
test case yet. Until I can reproduce the treelist-based bug on one of 
my machines I'm not sure how to proceed. I've been running the tests on 
my Mac OS X box, perhaps I need to see if I can reproduce the crashes 
under Linux.

Re: [Fxruby-users] Segfaults

[Gilles F. <gil...@fr...>]

Lyle Johnson a =E9crit :
>=20
> On Apr 5, 2004, at 10:48 AM, Gilles Filippini wrote:
[snip]
> OK. I saw the bug reports, but haven't had a chance to run the table=20
> test case yet. Until I can reproduce the treelist-based bug on one of m=
y=20
> machines I'm not sure how to proceed. I've been running the tests on my=
=20
> Mac OS X box, perhaps I need to see if I can reproduce the crashes unde=
r=20
> Linux.

Update:
* I rebooted my box to give the treelist test case a try using a fresh=20
system: same segfault at count=3D59.
* Tried the test case on two other machines (RedHat 7.2 and Debian=20
Woody): no segfault.
Since it seems I am for now the only one having this problem I propose=20
setting this bug low priority.
I would appreciate if someone using a Debian Sarge would run the test=20
case and report about it.

_gilles.

[The bug report on SF is updated accordingly to this post]