Bug 317661 (MONO74562) - [PPC, IO-LAYER-NO-DAEMON] io-layer-no-daemon shows PPC -O2 deadlock with mcs
Summary: [PPC, IO-LAYER-NO-DAEMON] io-layer-no-daemon shows PPC -O2 deadlock with mcs
Status: RESOLVED FIXED
Alias: MONO74562
Product: Mono: Runtime
Classification: Mono
Component: io-layer (show other bugs)
Version: 1.1
Hardware: Other Other
: P3 - Medium : Enhancement
Target Milestone: ---
Assignee: Mono Bugs
QA Contact: Mono Bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-04-10 01:56 UTC by Geoff Norton
Modified: 2007-09-15 21:24 UTC (History)
0 users

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Wiest 2007-09-15 19:13:01 UTC


---- Reported by grompf@sublimeintervention.com 2005-04-09 18:56:48 MST ----

I checked out Dicks new io-layer-no-deamon branch; and replaced the mono/io-layer directory 
with it; upon installing the new io-layer mcs on OSX can never compile it just hangs.

(it locks in CreateFile)

#0  0x90012588 in clock_sleep_trap ()
#1  0x9000d758 in nanosleep ()
#2  0x000c8cb4 in _wapi_handle_get_or_set_share (device=234881027, inode=1633126, 
new_sharemode=1, new_access=2147483648, old_sharemode=0xbffff190, 
old_access=0xbffff194, share_info=0xbffff254) at ../../mono/io-layer/handles-private.h:330
#3  0x000cf620 in share_allows_open (statbuf=0xe, sharemode=1, fileaccess=2147483648, 
share_info=0xbffff254) at io.c:1476
#4  0x000cf6cc in share_check (statbuf=0xbffff270, sharemode=1, fileaccess=2147483648, 
share_info=0xbffff254) at io.c:1534
#5  0x000cf880 in CreateFile (name=0x7, fileaccess=2147483648, sharemode=1, 
security=0x5f5e100, createmode=3221221504, attrs=128, template=0x3200) at io.c:1686
#6  0x000de6d4 in ves_icall_System_IO_MonoIO_Open (filename=0x1093fe0, mode=3, 
access_mode=0, share=1, async=0 '\0', error=0xbffff4e0) at file-io.c:519

-kangaroo



---- Additional Comments From dick@ximian.com 2005-04-09 19:14:43 MST ----

Works fine on my mac (10.3.8)



---- Additional Comments From grompf@sublimeintervention.com 2005-04-09 23:46:48 MST ----

Dick,

  Following up on our discussion today I have tried this on 2 OSX machines now (10.3.8 
gcc build 1671); both exhibit the same symptoms.

The g5 was a fresh install of the 1.1.6 framework, fresh checkout of mono and mcs, svn 
swtich svn+ssh://username@mono-cvs.ximian.com/source/branches/dick/io-layer-no-
daemon the io-layer directory;

./autogen.sh
make

it locks up on the first step of the make using the new runtime (building System.xml.dll)

the full backtrace on the g5 is:

(gdb) t a a bt

Thread 3 (process 7954 thread 0x1303):
#0  0x90016f48 in semaphore_wait_signal_trap ()
#1  0x9000e790 in _pthread_cond_wait ()
#2  0x000cb50c in _wapi_get_win32_file_error (err=5379) at error.c:141
#3  0x000bec30 in convert_family (mono_family=5379) at socket-io.c:137
#4  0x000b0bfc in intersect_ranges (ranges=0x1503, other_ranges=0x1603, delta=40, 
rela
tion=48) at abcremoval.c:724
#5  0x00065a88 in abort_appdomain_thread (key=0x1503, value=0x1d15c, 
user_data=0xfffff
fff) at threads.c:1888
#6  0x000d5088 in __bsd_dtoa (d=-6.3055886190221176e+231, mode=1289780, 
ndigits=0, dec
pt=0x0, sign=0x0, rve=0x0, resultp=0xffffffff) at strtod.c:2080
#7  0x900246e8 in _pthread_body ()

Thread 2 (process 7954 thread 0x113):
#0  0x90012588 in clock_sleep_trap ()
#1  0x9000d758 in nanosleep ()
#2  0x000cbfbc in GC_build_fl_clear2 (h=0x0, ofl=0x1 <Address 0x1 out of bounds>) at 
n
ew_hblk.c:67
#3  0x000e5f84 in cleanup () at daemon.c:100
#4  0x900246e8 in _pthread_body ()

Thread 1 (process 7954 thread 0x60f):
#0  0x90012588 in clock_sleep_trap ()
#1  0x9000d758 in nanosleep ()
#2  0x000cb780 in GetTickCount () at timefuncs.c:54
#3  0x000d22ec in _wapi_handle_fd_offset_store (fd=14, handle=0x42588fb8) at ../../
mon
o/io-layer/handles-private.h:260
#4  0x000d2398 in _wapi_handle_fd_offset_store (fd=14, handle=0x42588fb8) at ../../
mon
o/io-layer/handles-private.h:216
#5  0x000d254c in _wapi_handle_get_private_segment (segment=0) at ../../mono/io-
layer/
handles-private.h:126
#6  0x000e1610 in _wapi_accept (fd=1113100216, addr=0x13ae38, addrlen=0x5f5e100) 
at so
ckets.c:291
#7  0x0103da48 in ?? ()
#8  0x0103cf90 in ?? ()
#9  0x0103cc04 in ?? ()
#10 0x0103cb44 in ?? ()
#11 0x0103ca70 in ?? ()
#12 0x0103badc in ?? ()
#13 0x0103b76c in ?? ()
#14 0x0103b334 in ?? ()
#15 0x0103aedc in ?? ()
#16 0x005241dc in ?? ()
#17 0x00522288 in ?? ()
#18 0x0052148c in ?? ()
#19 0x000629b8 in mono_message_invoke (target=0x42588fb8, msg=0x5f5e100, 
exc=0x542440,
 out_args=0x13ae38) at object.c:3272
#20 0x00062608 in mono_raise_exception (ex=0x42588fb8) at object.c:3120
#21 0x00003d68 in mono_main (argc=0, argv=0x5f5e100) at driver.c:973
#22 0x00002100 in _dyld_init_check ()
#23 0x8fe1a558 in __dyld__dyld_start ()

the full backtrace on the g4 is:

Thread 3 (process 22661 thread 0x1303):
#0  0x90016f48 in semaphore_wait_signal_trap ()
#1  0x9000e790 in _pthread_cond_wait ()
#2  0x000c8a40 in _wapi_handle_scratch_store_internal (bytes=259, remap=0xffffffff) at 
handles.c:909
#3  0x000bc758 in SHA1Transform (state=0x0, buffer=0x1603 "y/Frameworks/
Mono.framework/Versions/1.1.5/lib/libglib-2.0.0.dylib") at mono-sha1.c:159
#4  0x000ae9bc in ves_icall_System_GC_WaitForPendingFinalizers () at gc.c:288
#5  0x000644ec in mono_store_remote_field_new (this=0x1818e00, klass=0x1, 
field=0x0, arg=0x13c56c) at object.c:3698
#6  0x000d22ec in FileTimeToSystemTime (file_time=0xa000448c, system_time=0x0) at 
io.c:2702
#7  0x900246e8 in _pthread_body ()

Thread 2 (process 22661 thread 0x113):
#0  0x90012588 in clock_sleep_trap ()
#1  0x9000d758 in nanosleep ()
#2  0x000c94bc in _wapi_handle_ops_signal (handle=0x1405008) at handles.c:1283
#3  0x000e2ff4 in _wapi_getsockopt (fd=1113100331, level=1277496, 
optname=1113100331, optval=0x0, optlen=0x5f5e100) at sockets.c:497
#4  0x900246e8 in _pthread_body ()

Thread 1 (process 22661 thread 0x60f):
#0  0x90012588 in clock_sleep_trap ()
#1  0x9000d758 in nanosleep ()
#2  0x000c8cb4 in _wapi_handle_scratch_store_string_array (data=0x0) at handles.c:1003
#3  0x000cf620 in file_write (handle=0x4258902b, buffer=0x137e38, numbytes=0, 
byteswritten=0x5f5e100, overlapped=0xbfffe8e0) at io.c:351
#4  0x000cf6cc in file_write (handle=0xbfffeab4, buffer=0x137e38, numbytes=0, 
byteswritten=0x5f5e100, overlapped=0xbfffe8e0) at io.c:394
#5  0x000cf880 in file_seek (handle=0x1370570, movedistance=-1073747248, 
highmovedistance=0x0, method=16) at io.c:492
#6  0x000de6d4 in ves_icall_System_Globalization_CultureInfo_construct_datetime_format 
(this=0xe) at locales.c:141
#7  0x012c2a38 in ?? ()
#8  0x012c1f88 in ?? ()
#9  0x012c1bfc in ?? ()
#10 0x012c1b3c in ?? ()
#11 0x012c1a68 in ?? ()
#12 0x012c0ae4 in ?? ()
#13 0x012c0774 in ?? ()
#14 0x012c033c in ?? ()
#15 0x012bfee4 in ?? ()
#16 0x007fa1a4 in ?? ()
#17 0x007f8260 in ?? ()
#18 0x007f746c in ?? ()
#19 0x0006155c in mono_runtime_run_main (method=0xffffffff, argc=100000000, 
argv=0xbfffead0, exc=0x0) at object.c:1733
#20 0x000611e0 in mono_get_delegate_invoke (klass=0xe) at object.c:1581
#21 0x00003e74 in mono_main (argc=0, argv=0x5f5e100) at driver.c:745
#22 0x000021d8 in ?? ()
#23 0x8fe1a558 in __dyld__dyld_start ()

-kangaroo




---- Additional Comments From mass@akuma.org 2005-04-10 03:44:50 MST ----

Me too:

I repeatedly get the message
** (../../class/lib/basic/mcs.exe:26314): WARNING **: _wapi_timestamp_exclusion: 
Breaking a previous timestamp

on the same file as kangaroo above, the first file compiled once switched to the 'local' 
mono build.

(gdb) thread apply all bt

Thread 3 (process 26314 thread 0x1403):
#0  0x9002ca78 in semaphore_wait_signal_trap ()
#1  0x9003125c in pthread_cond_wait ()
#2  0x000cfc38 in _wapi_handle_wait_signal_handle (handle=0x1703) at handles.c:1411
#3  0x000c38e0 in WaitForSingleObjectEx (handle=0x103, timeout=4294967295, 
alertable=1) at wait.c:118
#4  0x000b5d50 in finalizer_thread (unused=0x1703) at gc.c:674
#5  0x0006d88c in start_wrapper (data=0x111cc00) at threads.c:291
#6  0x000da038 in timed_thread_start_routine (args=0x111cc60) at timed-thread.c:134
#7  0x9002c3b4 in _pthread_body ()

Thread 2 (process 26314 thread 0x217):
#0  g_log (log_domain=0x0, log_level=G_LOG_LEVEL_WARNING, format=0x10b518 "%s: 
Breaking a previous timestamp") at gmessages.c:512
#1  0x000d0458 in _wapi_handle_update_refs () at ../../mono/io-layer/handles-private.h:
298
#2  0x000eb168 in collection_thread (unused=0x0) at collection.c:35
#3  0x9002c3b4 in _pthread_body ()

Thread 1 (process 26314 thread 0x10f):
#0  0x90042ac8 in mach_wait_until ()
#1  0x90042880 in nanosleep ()
#2  0x000cfeac in _wapi_handle_get_or_set_share (device=234881026, inode=557470, 
new_sharemode=1, new_access=2147483648, old_sharemode=0xbfffe448, 
old_access=0xbfffe44c, share_info=0xbfffe4bc) at ../../mono/io-layer/handles-private.h:
330
#3  0x000d923c in share_allows_open (statbuf=0x0, sharemode=1, 
fileaccess=2147483648, share_info=0xbfffe4bc) at io.c:1476
#4  0x000d9724 in CreateFile (name=0x11ba800, fileaccess=2147483648, 
sharemode=1, security=0xc402f, createmode=1113113568, attrs=128, template=0x0) at 
io.c:1534
#5  0x000e6590 in ves_icall_System_IO_MonoIO_Open (filename=0x0, mode=3, 
access_mode=1843164, share=1, async=0 '\0', error=0xbfffe750) at file-io.c:519
#6  0x017c9a38 in ?? ()
#7  0x017c8f88 in ?? ()
#8  0x017c8bfc in ?? ()
#9  0x017c8b3c in ?? ()
#10 0x017c8a68 in ?? ()
#11 0x017f21fc in ?? ()
#12 0x017f1ee8 in ?? ()
#13 0x004e0338 in ?? ()
#14 0x004de260 in ?? ()
#15 0x004dd46c in ?? ()
#16 0x00068a28 in mono_runtime_exec_main (method=0x0, args=0x2ecaa332, 
exc=0xbfffe750) at object.c:1888
#17 0x0006b6c8 in mono_runtime_run_main (method=0x0, argc=19, argv=0x100ff60, 
exc=0x0) at object.c:1751
#18 0x000041f4 in mono_main (argc=1310988, argv=0xbffff05c) at driver.c:527
#19 0x0000241c in _start (argc=24, argv=0xbffff05c, envp=0xbffff0c0) at /SourceCache/
Csu/Csu-57/crt.c:272
#20 0x000022bc in start ()
512     in gmessages.c



---- Additional Comments From dick@ximian.com 2005-04-11 08:47:25 MST ----

kangaroo: that backtrace looks bogus - the symbol
_wapi_handle_get_private_segment does not appear in the code any more,
and I'd be very surprised if the abcremoval code started making socket
calls.

You'll be pleased to know however that I've reproduced the deadlock. 
It happens if the runtime is built with optimisation enabled (-O2
here, I tend to build with CFLAGS set to just -g.)  This is a bug that
Paolo was looking at a couple of weeks ago, but I don't know if he got
to the bottom of it.




---- Additional Comments From lupus@ximian.com 2005-04-13 14:37:37 MST ----

I fixed this in svn: gcc seems to miscompile some inline asm code.


Unknown bug field "cf_op_sys_details" encountered while moving bug
   <cf_op_sys_details>OSX 10.3.8</cf_op_sys_details>
Unknown operating system unknown. Setting to default OS "Other".