Bug #5493: Commit r33357 breaks build on Debian/sparc

• Status: Rejected
• Assignee: ngoto (Naohisa Goto)
• Target version: -
• ruby -v: ruby 1.9.4dev (2011-09-29 trunk 33357) [sparc64-linux]

[jurij (Jurij Smakov)]

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: *** [exts.mk] 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" --command-output=exts.mk --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: *** [exts.mk] 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.

[jurij (Jurij Smakov)]

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.

[jurij (Jurij Smakov)]

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.

[ko1 (Koichi Sasada)]

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

[mame (Yusuke Endoh)]

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

Hello,

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 [e-mail]

[ngoto (Naohisa Goto)]

• Status changed from Assigned to Feedback

I cannot reproduce it on sparc Solaris 10.

[drbrain (Eric Hodel)]

• Status changed from Feedback to Rejected

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