Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > segfaults on mandrake...

Reply
Thread Tools

segfaults on mandrake...

 
 
Ferenc Engard
Guest
Posts: n/a
 
      01-18-2004
Hello,

I have reproducible, but not constant segfaults (sometimes hangups) on
Mandrake 9.2 (download edition, or what -- I do not use it
frequently).

The packages:

ruby-tk-1.8.1-1mdk
ruby-mysql-2.4.5-1
ruby-dbi-0.0.21-1
ruby-1.8.1-1mdk

Ruby version:
ruby 1.8.1 (2003-12-25) [i586-linux-gnu]

Some segfault places:

/usr/lib/ruby/site_ruby/1.8/DBD/Mysql/Mysql.rb:418: [BUG] Segmentation
fault
ruby 1.8.1 (2003-12-25) [i586-linux-gnu]

/usr/lib/ruby/site_ruby/1.8/DBD/Mysql/Mysql.rb:425: [BUG] Segmentation
fault
ruby 1.8.1 (2003-12-25) [i586-linux-gnu]

/usr/lib/ruby/site_ruby/1.8/dbi/row.rb:39: [BUG] Segmentation fault
ruby 1.8.1 (2003-12-25) [i586-linux-gnu]

(eval):762: [BUG] Segmentation fault
ruby 1.8.1 (2003-12-25) [i586-linux-gnu]

Sometimes also segfaults in my code. The program makes heavy
DBI::StatementHandle using (and output to stdout) when the crash
occurs.

This is a P4 celeron 2100MHz machine. On my home machine, which is a
P233, which is a also a 1.8.1 (2003-11-11), the crash never occurs.

Any tips?

Ferenc


 
Reply With Quote
 
 
 
 
nobu.nokada@softhome.net
Guest
Posts: n/a
 
      01-18-2004
Hi,

At Mon, 19 Jan 2004 06:51:04 +0900,
Ferenc Engard wrote:
> This is a P4 celeron 2100MHz machine. On my home machine, which is a
> P233, which is a also a 1.8.1 (2003-11-11), the crash never occurs.


Sounds like concerning to pthread support. Try with CVS HEAD
version. And can't you get stack trace from core?

--
Nobu Nakada


 
Reply With Quote
 
 
 
 
Ferenc Engard
Guest
Posts: n/a
 
      01-19-2004
On Mon, 19 Jan 2004 http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:

>Hi,
>
>At Mon, 19 Jan 2004 06:51:04 +0900,
>Ferenc Engard wrote:
>> This is a P4 celeron 2100MHz machine. On my home machine, which is a
>> P233, which is a also a 1.8.1 (2003-11-11), the crash never occurs.

>
>Sounds like concerning to pthread support. Try with CVS HEAD
>version. And can't you get stack trace from core?


I have tried on another debian with the actual ruby package
(2003-12-27), and it didn't segfaulted. So it is possible that the
problem is not with ruby.

How can I core dump? Right now, I am not at the machine, so apologize
if it dumps core automatically.

If it is possible, I wouldn't try the CVS version, as I have a real
tight deadline to deliver my program (hence this new distro-related
problem).

I guess my glibc (pthreads) version is 2.3.2.

It is a real big problem to me, if I cannot install my script to these
mdk boxes... ((

Thanks,
Ferenc


 
Reply With Quote
 
Ferenc Engard
Guest
Posts: n/a
 
      01-19-2004
Hello,

I still cannot know how to dump core, but running 3 times from gdb
caused 3 segfaults in different places.

I am totally helpless. What can I do?

Ferenc

Here are the backtraces (sorry about the long mail):

(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x401aef9f in realloc () from /lib/i686/libc.so.6
(gdb) bt
#0 0x401aef9f in realloc () from /lib/i686/libc.so.6
#1 0x40061e68 in ruby_xrealloc () from /usr/lib/libruby.so.1.8
#2 0x400ad33a in rb_str_update () from /usr/lib/libruby.so.1.8
#3 0x400505a8 in rb_frame_last_func () from /usr/lib/libruby.so.1.8
#4 0x40045cb5 in rb_eval_string () from /usr/lib/libruby.so.1.8
#5 0x4004ded9 in rb_rescue2 () from /usr/lib/libruby.so.1.8
#6 0x40018822 in lib_watchdog_ensure ()
from /usr/lib/ruby/1.8/i586-linux-gnu/tcltklib.so
#7 0x4004e11e in rb_ensure () from /usr/lib/libruby.so.1.8
#8 0x40018905 in lib_watchdog_ensure ()
from /usr/lib/ruby/1.8/i586-linux-gnu/tcltklib.so
(gdb)



(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x400a9fd0 in st_free_table () from /usr/lib/libruby.so.1.8
(gdb) bt
#0 0x400a9fd0 in st_free_table () from /usr/lib/libruby.so.1.8
#1 0x4006342f in rb_gc_force_recycle () from /usr/lib/libruby.so.1.8
#2 0x40063188 in rb_gc_mark () from /usr/lib/libruby.so.1.8
#3 0x400638b9 in rb_gc () from /usr/lib/libruby.so.1.8
#4 0x40062269 in rb_newobj () from /usr/lib/libruby.so.1.8
#5 0x4004ecf3 in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#6 0x4004f59f in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#7 0x400486bc in rb_Array () from /usr/lib/libruby.so.1.8
#8 0x4004adef in rb_Array () from /usr/lib/libruby.so.1.8
#9 0x4004cf0a in rb_iterator_p () from /usr/lib/libruby.so.1.8
#10 0x4004d217 in rb_yield_values () from /usr/lib/libruby.so.1.8
#11 0x400408e9 in rb_each () from /usr/lib/libruby.so.1.8
#12 0x4004ce97 in rb_iterator_p () from /usr/lib/libruby.so.1.8
#13 0x4004d151 in rb_yield () from /usr/lib/libruby.so.1.8
#14 0x40033472 in rb_ary_each () from /usr/lib/libruby.so.1.8
#15 0x4005c1fa in rb_throw () from /usr/lib/libruby.so.1.8
#16 0x4004f1fd in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#17 0x4004f59f in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#18 0x4004f903 in rb_funcall () from /usr/lib/libruby.so.1.8
#19 0x4003f957 in rb_each () from /usr/lib/libruby.so.1.8
#20 0x4004da29 in rb_iterate () from /usr/lib/libruby.so.1.8
#21 0x40040963 in rb_each () from /usr/lib/libruby.so.1.8
#22 0x4005c1fa in rb_throw () from /usr/lib/libruby.so.1.8
#23 0x4004f1fd in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#24 0x4004f59f in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#25 0x400486bc in rb_Array () from /usr/lib/libruby.so.1.8
#26 0x4004b523 in rb_Array () from /usr/lib/libruby.so.1.8
#27 0x4004ef97 in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#28 0x4004f59f in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#29 0x400486bc in rb_Array () from /usr/lib/libruby.so.1.8
#30 0x4004b4e5 in rb_Array () from /usr/lib/libruby.so.1.8
#31 0x4004ef97 in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#32 0x4004f59f in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#33 0x400486bc in rb_Array () from /usr/lib/libruby.so.1.8
#34 0x4004993f in rb_Array () from /usr/lib/libruby.so.1.8
#35 0x4004ef97 in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#36 0x4004f59f in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#37 0x400486bc in rb_Array () from /usr/lib/libruby.so.1.8
#38 0x4004870d in rb_Array () from /usr/lib/libruby.so.1.8
---Type <return> to continue, or q <return> to quit---
#39 0x4004870d in rb_Array () from /usr/lib/libruby.so.1.8
#40 0x4004870d in rb_Array () from /usr/lib/libruby.so.1.8
#41 0x4004993f in rb_Array () from /usr/lib/libruby.so.1.8
#42 0x4004cf0a in rb_iterator_p () from /usr/lib/libruby.so.1.8
#43 0x4004d151 in rb_yield () from /usr/lib/libruby.so.1.8
#44 0x40079204 in rb_fix2str () from /usr/lib/libruby.so.1.8
#45 0x4005c1fa in rb_throw () from /usr/lib/libruby.so.1.8
#46 0x4004f1fd in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#47 0x4004f59f in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#48 0x400486bc in rb_Array () from /usr/lib/libruby.so.1.8
#49 0x4004b523 in rb_Array () from /usr/lib/libruby.so.1.8
#50 0x4004ef97 in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#51 0x4004f59f in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#52 0x400486bc in rb_Array () from /usr/lib/libruby.so.1.8
#53 0x40048965 in rb_Array () from /usr/lib/libruby.so.1.8
#54 0x4004ef97 in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#55 0x4004f59f in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#56 0x400486bc in rb_Array () from /usr/lib/libruby.so.1.8
#57 0x4004cf0a in rb_iterator_p () from /usr/lib/libruby.so.1.8
#58 0x400548a1 in rb_f_lambda () from /usr/lib/libruby.so.1.8
#59 0x400549c8 in rb_f_lambda () from /usr/lib/libruby.so.1.8
#60 0x4005c1c6 in rb_throw () from /usr/lib/libruby.so.1.8
#61 0x4004f1fd in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#62 0x4004f59f in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#63 0x4004f9ab in rb_funcall2 () from /usr/lib/libruby.so.1.8
#64 0x400462d0 in rb_eval_cmd () from /usr/lib/libruby.so.1.8
#65 0x4001f966 in _init () from /usr/lib/ruby/1.8/i586-linux-gnu/tkutil.so
#66 0x4005c1e4 in rb_throw () from /usr/lib/libruby.so.1.8
#67 0x4004f1fd in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#68 0x4004f59f in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#69 0x400486bc in rb_Array () from /usr/lib/libruby.so.1.8
#70 0x4004cf0a in rb_iterator_p () from /usr/lib/libruby.so.1.8
#71 0x400548a1 in rb_f_lambda () from /usr/lib/libruby.so.1.8
#72 0x400549c8 in rb_f_lambda () from /usr/lib/libruby.so.1.8
#73 0x4005c1c6 in rb_throw () from /usr/lib/libruby.so.1.8
#74 0x4004f1fd in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#75 0x4004f59f in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#76 0x4004f9ab in rb_funcall2 () from /usr/lib/libruby.so.1.8
#77 0x400462d0 in rb_eval_cmd () from /usr/lib/libruby.so.1.8
---Type <return> to continue, or q <return> to quit---
#78 0x4001f966 in _init () from /usr/lib/ruby/1.8/i586-linux-gnu/tkutil.so
#79 0x4005c1e4 in rb_throw () from /usr/lib/libruby.so.1.8
#80 0x4004f1fd in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#81 0x4004f59f in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#82 0x400486bc in rb_Array () from /usr/lib/libruby.so.1.8
#83 0x4004ae1b in rb_Array () from /usr/lib/libruby.so.1.8
#84 0x4004ef97 in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#85 0x4004f59f in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#86 0x400486bc in rb_Array () from /usr/lib/libruby.so.1.8
#87 0x4004ef97 in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#88 0x4004f59f in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#89 0x400486bc in rb_Array () from /usr/lib/libruby.so.1.8
#90 0x4004ef97 in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#91 0x4004f59f in rb_with_disable_interrupt () from /usr/lib/libruby.so.1.8
#92 0x400486bc in rb_Array () from /usr/lib/libruby.so.1.8
#93 0x400503e1 in rb_frame_last_func () from /usr/lib/libruby.so.1.8
#94 0x40045cb5 in rb_eval_string () from /usr/lib/libruby.so.1.8
#95 0x4004ded9 in rb_rescue2 () from /usr/lib/libruby.so.1.8
#96 0x40018822 in lib_watchdog_ensure ()
from /usr/lib/ruby/1.8/i586-linux-gnu/tcltklib.so
#97 0x4004e11e in rb_ensure () from /usr/lib/libruby.so.1.8
#98 0x40018905 in lib_watchdog_ensure ()
from /usr/lib/ruby/1.8/i586-linux-gnu/tcltklib.so



(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x401afb5d in mallopt () from /lib/i686/libc.so.6
(gdb) bt
#0 0x401afb5d in mallopt () from /lib/i686/libc.so.6
#1 0x401aecb8 in malloc () from /lib/i686/libc.so.6
(gdb)





 
Reply With Quote
 
nobu.nokada@softhome.net
Guest
Posts: n/a
 
      01-19-2004
Hi,

At Tue, 20 Jan 2004 07:42:41 +0900,
Ferenc Engard wrote:
> I still cannot know how to dump core, but running 3 times from gdb
> caused 3 segfaults in different places.


Try "ulimit -c unlimited" to make core.

> Here are the backtraces (sorry about the long mail):


All seem related with GC. I guess it might be fixed in CVS
HEAD, or disapper by configuring with --disable-pthread.

--
Nobu Nakada


 
Reply With Quote
 
Ferenc Engard
Guest
Posts: n/a
 
      01-20-2004
(E-Mail Removed) wrote:
>
> Hi,
>
> At Tue, 20 Jan 2004 07:42:41 +0900,
> Ferenc Engard wrote:
> > I still cannot know how to dump core, but running 3 times from gdb
> > caused 3 segfaults in different places.

>
> Try "ulimit -c unlimited" to make core.
>
> > Here are the backtraces (sorry about the long mail):

>
> All seem related with GC. I guess it might be fixed in CVS
> HEAD, or disapper by configuring with --disable-pthread.


Does it affect multithreading (i.e., tk)?

Anyway, it seems that the problem exists only on mandrake, even with
newer ruby than on my debian box. The latest one was tried is
2003-12-27, and on debian I was happy with 2003-11-11. Are you sure
compiling the HEAD version solves the problem?

Nobody uses mandrake here?

Ferenc


 
Reply With Quote
 
Yukihiro Matsumoto
Guest
Posts: n/a
 
      01-20-2004
Hi,

In message "Re: segfaults on mandrake..."
on 04/01/20, Ferenc Engard <(E-Mail Removed)> writes:
|>
|> All seem related with GC. I guess it might be fixed in CVS
|> HEAD, or disapper by configuring with --disable-pthread.
|
|Does it affect multithreading (i.e., tk)?

Depends on your platform. If your tcltk is linked with -lpthread,
-enable-pthread is necessary.

matz.


 
Reply With Quote
 
nobu.nokada@softhome.net
Guest
Posts: n/a
 
      01-20-2004
Hi,

At Tue, 20 Jan 2004 15:14:49 +0900,
Ferenc Engard wrote:
> > > Here are the backtraces (sorry about the long mail):

> >
> > All seem related with GC. I guess it might be fixed in CVS
> > HEAD, or disapper by configuring with --disable-pthread.

>
> Does it affect multithreading (i.e., tk)?


It should have worked before --enable-pthread was introduced.

> Anyway, it seems that the problem exists only on mandrake, even with
> newer ruby than on my debian box. The latest one was tried is
> 2003-12-27, and on debian I was happy with 2003-11-11. Are you sure
> compiling the HEAD version solves the problem?


Though I'm not sure, there are some fixes which are not
backported to 1.8 yet.

--
Nobu Nakada


 
Reply With Quote
 
Ferenc Engard
Guest
Posts: n/a
 
      01-20-2004
On Tue, 20 Jan 2004, Yukihiro Matsumoto wrote:

>Hi,
>
>In message "Re: segfaults on mandrake..."
> on 04/01/20, Ferenc Engard <(E-Mail Removed)> writes:
>|>
>|> All seem related with GC. I guess it might be fixed in CVS
>|> HEAD, or disapper by configuring with --disable-pthread.
>|
>|Does it affect multithreading (i.e., tk)?
>
>Depends on your platform. If your tcltk is linked with -lpthread,
>-enable-pthread is necessary.


Yes, it does.

fery@cirmi:~$ ldd /usr/lib/libtk8.4.so.0
libpthread.so.0 => /lib/libpthread.so.0 (0x400e0000)
[...]


Ferenc


 
Reply With Quote
 
Ferenc Engard
Guest
Posts: n/a
 
      01-20-2004
On Tue, 20 Jan 2004 (E-Mail Removed) wrote:

>Hi,
>
>At Tue, 20 Jan 2004 15:14:49 +0900,
>Ferenc Engard wrote:
>> > > Here are the backtraces (sorry about the long mail):
>> >
>> > All seem related with GC. I guess it might be fixed in CVS
>> > HEAD, or disapper by configuring with --disable-pthread.

>>
>> Does it affect multithreading (i.e., tk)?

>
>It should have worked before --enable-pthread was introduced.
>
>> Anyway, it seems that the problem exists only on mandrake, even with
>> newer ruby than on my debian box. The latest one was tried is
>> 2003-12-27, and on debian I was happy with 2003-11-11. Are you sure
>> compiling the HEAD version solves the problem?

>
>Though I'm not sure, there are some fixes which are not
>backported to 1.8 yet.


As there were no other suggestions, I try to do my first ruby
compiling... (

Mandrake uses many dist-specific patches to libc. Cannot be the
problem connected with one of these patches?

Ferenc

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
fixing random segfaults Skeleton Man Perl 0 06-04-2006 03:35 PM
axis cpp questions ...?wsdl segfaults Rob Yampolsky Java 0 05-03-2005 03:50 PM
Statically-linked binary SegFaults David Douthitt C Programming 1 05-20-2004 09:47 PM
Weird segfaults Naveen Parihar C++ 3 04-06-2004 06:18 AM
sprintf segfaults Robert Mens C Programming 3 10-25-2003 11:52 PM



Advertisments