Bug #2641

Seg fault running miniruby during ruby build on Haiku

Added by Alexander von Gluck over 5 years ago. Updated about 4 years ago.

[ruby-core:27778]
Status:Rejected
Priority:Normal
Assignee:-
ruby -v:ruby 1.8.4 (2005-12-24) [i586-beos] Backport:

Description

=begin
Not sure whats triggering it, enabled debugging in thread.c as thats around where the cause seems to be.

r26400

see attached for log output of build.

rubyseg.txt -- first build
rubyseg2.txt -- results of running make again.
=end

rubyseg.txt Magnifier - first build (41 KB) Alexander von Gluck, 01/25/2010 02:55 PM

rubyseg2.txt Magnifier - results of running make after first failure (9.34 KB) Alexander von Gluck, 01/25/2010 02:55 PM

patch.diff Magnifier (1.06 KB) Alexander von Gluck, 01/31/2010 08:02 AM

History

#1 Updated by Alexander von Gluck over 5 years ago

=begin
and just to make sure it's not Haiku's fault...

http://dev.haiku-os.org/ticket/5321
=end

#2 Updated by Alexander von Gluck over 5 years ago

=begin
a quick note.. still not sure if it is a Haiku or Ruby issue. Here is a gdb backtrace of the seg fault...

GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i586-pc-haiku"...
[tcsetpgrp failed in terminal_inferior: Invalid Argument]
Thread 8823 caused an exception: Segment violation
Reading symbols from /boot/system/runtime_loader...done.
Loaded symbols for /boot/system/runtime_loader
Reading symbols from /boot/system/lib/gcc4/libroot.so...done.
Loaded symbols for /boot/system/lib/gcc4/libroot.so
[tcsetpgrp failed in terminal_inferior: Invalid Argument]
[Switching to team ./miniruby -I./lib -I.ext/common -I./- -r./ext/purelib.rb ./too (8822) thread pthread func (8823)]
0x002471ee in report_bug (file=0xffffffff ,
line=-1, fmt=0x365d05 "%s: %s (%s)", args=0x70004f38 "S\2068")
at error.c:216
216 {
(gdb) bt
#0 0x002471ee in report_bug (
file=0xffffffff , line=-1,
fmt=0x365d05 "%s: %s (%s)", args=0x70004f38 "S\2068") at error.c:216
#1 0x00247392 in rb_bug (fmt=0x365d05 "%s: %s (%s)") at error.c:245
#2 0x0024797b in rb_bug_errno (mesg=0x388653 "thread_timer/timedwait",
errno_arg=3704403) at error.c:259
#3 0x0035ed6f in thread_timer (dummy=0x0) at thread_pthread.c:769
#4 0x004020fb in pthread_thread_entry () from /boot/system/lib/gcc4/libroot.so
#5 0x70004fec in ?? ()
=end

#3 Updated by Roger Pack over 5 years ago

=begin
are you really using 1.8.4? What about trunk?

-r
=end

#4 Updated by Alexander von Gluck over 5 years ago

=begin
trying to use an older binary version of 1.8 for BeOS to compile 1.9 on Haiku.

(compiling ruby requires ruby which is kind of silly but whatever)

It seems like miniruby is locking up accessing BUFSIZ...

adding the following to the top of the rb_bug function in error.c causes to lockup to happen on the second printf instead of when report_bug references it.

printf("rb_bug!!\n\n");
printf("buffer size: %i",BUFSIZE);

Tested the same code outsize of error.c in a simple app on Haiku and it works as expected with a buffer size of 8192.
=end

#5 Updated by Yui NARUSE over 5 years ago

=begin
The gdb backtrace says, Haiku's pthread_cond_timedwait returns 3704403, but the value is not ETIMEDOUT nor EINTR.

-- Ruby accepts only 0, EINTR, ETIMEDOUT
http://redmine.ruby-lang.org/repositories/entry/ruby-19/thread_pthread.c

-- Haiku returns various values
http://dev.haiku-os.org/browser/haiku/trunk/src/system/libroot/posix/pthread/pthread_cond.c

So this is Ruby's issue while Haiku is on POSIX.
=end

#6 Updated by Alexander von Gluck over 5 years ago

=begin
Still working on the SegFault issues, there was some previous work for Ruby on Haiku done below by augiedoggie here: http://ports.haiku-files.org/wiki/dev-lang/ruby/1.9.1/1

I applied his patches (that weren't included in my previous patches) to a more recent source tree. They are attached but unfortunately don't help this crash issue in mainline on Haiku.
=end

#7 Updated by Yui NARUSE over 5 years ago

=begin
The patch seems for the signal problem which was mentioned before.
This seems different problem...

Anyway can you find the commit which breaks compile on Haiku?
You could compile it ten days ago.
=end

#8 Updated by Yusuke Endoh about 5 years ago

  • Status changed from Open to Feedback
  • Priority changed from Normal to 3
  • Target version set to 2.0.0

=begin
I set this ticket to Low priority because there is no maintainer
for Haiku. Contribution is welcome.

--
Yusuke Endoh mame@tsg.ne.jp
=end

#9 Updated by Yui NARUSE over 4 years ago

=begin
What's going on?
=end

#10 Updated by Yui NARUSE about 4 years ago

  • Status changed from Feedback to Rejected

timeout

Also available in: Atom PDF