Bug #5493


Commit r33357 breaks build on Debian/sparc

Added by jurij (Jurij Smakov) over 10 years ago. Updated over 9 years ago.

Target version:
ruby -v:
ruby 1.9.4dev (2011-09-29 trunk 33357) [sparc64-linux]


While trying to build the Ruby SVN nightly snapshot I found that it fails while configuring fiddle:

configuring digest/sha2
configuring dl
configuring dl/callback
configuring dl/win32
Failed to configure dl/win32. It will not be installed.
configuring etc
configuring fcntl
configuring fiber
configuring fiddle
[FATAL] Failed to create timer thread (errno: 14)
make: *** [] Error 1

The actual failing invocation:

making encs
make[1]: Entering directory /home/jurij/ruby/rubysvn' make[1]: Leaving directory /home/jurij/ruby/rubysvn'
./miniruby -I./lib -I. -I.ext/common ./ext/extmk.rb --make="make" --dest-dir="" --extout=".ext" --mflags="" --make-flags="" --extension --extstatic --make-flags="V=0 MINIRUBY='./miniruby -I./lib -I. -I.ext/common '" -- configure
configuring fiddle
[FATAL] Failed to create timer thread (errno: 14)
make: *** [] Error 1

After a bit of bisecting I found that r33356 is the last good revision, the failure appears in r33357 ("use RTYPE_P which is optimized for constant types, instead of comparison with TYPE."). The system is up-to-date Debian-sid/sparc. I can provide the build logs and do additional tests if necessary.

Updated by jurij (Jurij Smakov) over 10 years ago

Ok, the story is probably more complicated than just this commit breaking it. I tried reverting r33357 in the latest SVN snapshot, and it still fails when configuring fiddle.

Updated by jurij (Jurij Smakov) over 10 years ago

I've noticed that a failure to create a timer thread causes the following to appear in dmesg:

[ 2047.656289] FAULT[miniruby:2299]: 32-bit process reports 64-bit fault address [16fdf6d9d]
[ 2047.764409] TSTATE: 0000008011001600 TPC: 00000000005e0af4 TNPC: 00000000005e0af8 Y: 00000000 Tainted: G O
[ 2047.905352] TPC: <___copy_in_user+0x34/0xe0>
[ 2047.968213] g0: 0000000000422e10 g1: 0000000000000000 g2: 0310040001010080 g3: 0310071101010080
[ 2048.085886] g4: fffff8007f4259a0 g5: fffff800012ac000 g6: fffff8007f2d4000 g7: 00000000000000c0
[ 2048.204116] o0: 000000016fdf73e8 o1: 00000000ffdedfa8 o2: 0000000000000000 o3: 00000001ffdfffe8
[ 2048.323111] o4: ffffffff00212050 o5: 0000000000000000 sp: fffff8007f2d73a1 ret_pc: 000000000042b7e4
[ 2048.447014] RPC: <copy_thread+0x15c/0x238>
[ 2048.511850] l0: fffff8007cde4000 l1: 000000016fdf73e8 l2: 00000000ffdedfa8 l3: ffffffff00212058
[ 2048.633596] l4: 000000000000000f l5: 0000000000000001 l6: 0000000000000000 l7: 0000000000000008
[ 2048.755984] i0: 00000000003d0f00 i1: 0000000070009440 i2: 0000000000000000 i3: fffff8007f0ff9c0
[ 2048.878724] i4: fffff8007f2d7f60 i5: 0000000000000000 i6: fffff8007f2d7451 i7: 00000000004646ac
[ 2049.002003] I7: <copy_process+0x7d4/0xd50>
[ 2049.070428] Call Trace:
[ 2049.119099] [00000000004646ac] copy_process+0x7d4/0xd50
[ 2049.203064] [0000000000464d40] do_fork+0xec/0x294
[ 2049.281012] [000000000042b66c] sparc_do_fork+0x30/0x4c
[ 2049.364563] [0000000000406154] linux_sparc_syscall32+0x34/0x40

So, in the process of new thread creation some user-space memory copies are performed, and at some point we get a bogus address.

Updated by ko1 (Koichi Sasada) over 10 years ago

  • Status changed from Open to Assigned
  • Assignee set to mame (Yusuke Endoh)

Updated by mame (Yusuke Endoh) over 10 years ago

  • Assignee changed from mame (Yusuke Endoh) to ngoto (Naohisa Goto)


I can't check this ticket because I have no sparc machine.
Goto-san, could you check it?

r33357 itself looks simple and benign. But it is also big
and tedious, so there may be a careless mistake.

Yusuke Endoh

Updated by ngoto (Naohisa Goto) over 10 years ago

  • Status changed from Assigned to Feedback

I cannot reproduce it on sparc Solaris 10.

Updated by drbrain (Eric Hodel) over 9 years ago

  • Status changed from Feedback to Rejected

No feedback from the submitter after a failure to reproduce, so I am rejecting this.


Also available in: Atom PDF