Bug 486942 - WinForms apps not exiting cleanly
Summary: WinForms apps not exiting cleanly
Status: NEW
Alias: None
Product: UI Automation
Classification: Mono
Component: Winforms - General (show other bugs)
Version: Release 1.0
Hardware: x86 openSUSE 11.0
: P2 - High : Critical
Target Milestone: Release 1.1
Assignee: E-mail List
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-19 17:41 UTC by Brian Merrell
Modified: 2009-07-14 16:08 UTC (History)
0 users

See Also:
Found By: Integration Test
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 Brian Merrell 2009-03-19 17:41:49 UTC
PROBLEM STATEMENT

I can't duplicate this every time, but it happens fairly often.  I am still getting stacktraces or occasional hangs (requiring the use of ctrl+c) when exiting WinForms applications.  It seems that once the problem has been duplicated once, it happens every time.  A reboot seems to fix the problem for a while until it happens again.

REPRO

I have reproduced this on 1.0 using two sample applications:

splitter_horizontal.py
maskedtextbox.py

I recommend just opening and closing one of them several times.  If that doesn't work try poking them with Accerciser and then opening and closing them.  Also try leaving Accerciser open while opening and closing them.

RESULTS

When closing the application I see one of two things:

(1) the application exits with a non-zero exit status of 134 and prints a stacktrace like the one below

Native stacktrace:

	/usr/bin/mono [0x80cc3f4]
	/usr/bin/mono [0x805d808]
	[0xffffe410]
	/usr/lib/libORBit-2.so.0(giop_thread_request_push+0xdc) [0xb5cd575c]
	/usr/lib/libORBit-2.so.0 [0xb5cef4bb]
	/usr/lib/libORBit-2.so.0(ORBit_handle_request+0x52) [0xb5cf1502]
	/usr/lib/libORBit-2.so.0(giop_connection_handle_input+0x3a5) [0xb5cd98a5]
	/usr/lib/libORBit-2.so.0 [0xb5cf8c03]
	/usr/lib/libORBit-2.so.0 [0xb5cfb396]
	/usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x1e9) [0xb7f362d9]
	/usr/lib/libglib-2.0.so.0 [0xb7f3985b]
	/usr/lib/libglib-2.0.so.0(g_main_loop_run+0x1ca) [0xb7f39d2a]
	/usr/lib/libORBit-2.so.0 [0xb5cf6e00]
	/usr/lib/libglib-2.0.so.0 [0xb7f6039f]
	/lib/libpthread.so.0 [0xb7eb4175]
	/lib/libc.so.6(clone+0x5e) [0xb7e11dce]

Debug info from gdb:

Cannot access memory at address 0x20
[Thread debugging using libthread_db enabled]
[New Thread 0xb7d43900 (LWP 4747)]
[New Thread 0xb5bedb90 (LWP 4752)]
[New Thread 0xb758bb90 (LWP 4749)]
[New Thread 0xb75afb90 (LWP 4748)]
0x081e55d1 in GC_clear_hdr_marks (hhdr=0x405f78)
    at /usr/include/bits/string3.h:85
85	  return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest));
  4 Thread 0xb75afb90 (LWP 4748)  0xffffe430 in __kernel_vsyscall ()
  3 Thread 0xb758bb90 (LWP 4749)  0xffffe430 in __kernel_vsyscall ()
  2 Thread 0xb5bedb90 (LWP 4752)  0xffffe430 in __kernel_vsyscall ()
  1 Thread 0xb7d43900 (LWP 4747)  0x081e55d1 in GC_clear_hdr_marks (
    hhdr=0x405f78) at /usr/include/bits/string3.h:85

Thread 4 (Thread 0xb75afb90 (LWP 4748)):
#0  0xffffe430 in __kernel_vsyscall ()
#1  0xb7ebb3e6 in nanosleep () from /lib/libpthread.so.0
#2  0x081af4a8 in collection_thread (unused=0x0) at collection.c:34
#3  0xb7eb4175 in start_thread () from /lib/libpthread.so.0
#4  0xb7e11dce in clone () from /lib/libc.so.6

Thread 3 (Thread 0xb758bb90 (LWP 4749)):
#0  0xffffe430 in __kernel_vsyscall ()
#1  0xb7eb9ee5 in sem_wait@@GLIBC_2.1 () from /lib/libpthread.so.0
#2  0x080ff3d9 in finalizer_thread (unused=0x0) at gc.c:1058
#3  0x0818ff48 in start_wrapper (data=0x82e0bd8) at threads.c:623
#4  0x081c6bb6 in thread_start_routine (args=0x82d6814) at threads.c:286
#5  0x081db135 in GC_start_routine (arg=0x26f20) at pthread_support.c:1382
#6  0xb7eb4175 in start_thread () from /lib/libpthread.so.0
#7  0xb7e11dce in clone () from /lib/libc.so.6

Thread 2 (Thread 0xb5bedb90 (LWP 4752)):
#0  0xffffe430 in __kernel_vsyscall ()
#1  0xb7ebabab in read () from /lib/libpthread.so.0
#2  0x080cc596 in mono_handle_native_sigsegv (signal=11, ctx=0xb5becd8c)
    at /usr/include/bits/unistd.h:45
#3  0x0805d808 in sigsegv_signal_handler (_dummy=11, info=0xb5becd0c, 
    context=0xb5becd8c) at mini.c:4241
#4  <signal handler called>
#5  0xb7eb5568 in pthread_mutex_lock () from /lib/libpthread.so.0
#6  0xb5cd575c in giop_thread_request_push () from /usr/lib/libORBit-2.so.0
#7  0xb5cef4bb in ?? () from /usr/lib/libORBit-2.so.0
#8  0xb5cf1502 in ORBit_handle_request () from /usr/lib/libORBit-2.so.0
#9  0xb5cd98a5 in giop_connection_handle_input () from /usr/lib/libORBit-2.so.0
#10 0xb5cf8c03 in ?? () from /usr/lib/libORBit-2.so.0
#11 0xb5cfb396 in ?? () from /usr/lib/libORBit-2.so.0
#12 0xb7f362d9 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#13 0xb7f3985b in ?? () from /usr/lib/libglib-2.0.so.0
#14 0xb7f39d2a in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#15 0xb5cf6e00 in ?? () from /usr/lib/libORBit-2.so.0
#16 0xb7f6039f in ?? () from /usr/lib/libglib-2.0.so.0
#17 0xb7eb4175 in start_thread () from /lib/libpthread.so.0
#18 0xb7e11dce in clone () from /lib/libc.so.6

Thread 1 (Thread 0xb7d43900 (LWP 4747)):
#0  0x081e55d1 in GC_clear_hdr_marks (hhdr=0x405f78)
    at /usr/include/bits/string3.h:85
#1  0x081db5c4 in GC_apply_to_all_blocks (
    fn=0x81e55e0 <clear_marks_for_block>, client_data=0) at headers.c:274
#2  0x081e569a in GC_clear_marks () at mark.c:220
#3  0x081e2cfd in GC_try_to_collect_inner (
    stop_func=0x81e1ee0 <GC_never_stop_func>) at alloc.c:377
#4  0x081e3120 in GC_try_to_collect (stop_func=0x81e1ee0 <GC_never_stop_func>)
    at alloc.c:809
#5  0x081e31b2 in GC_gcollect () at alloc.c:822
#6  0xb5b81284 in ?? ()
#7  0xb5b811d4 in ?? ()
#8  0xb5b8119b in ?? ()
#9  0xb6f18b24 in ?? ()
#10 0x08112644 in mono_runtime_delegate_invoke (delegate=0x300a80, 
    params=0xbfee7e00, exc=0xbfee7e08) at object.c:2943
#11 0x08115827 in mono_runtime_run_main (method=0x82bbf6c, argc=2, 
    argv=0xbfee8018, exc=0x0) at object.c:2992
#12 0x080b3dfa in mono_main (argc=3, argv=0xbfee8014) at driver.c:969
#13 0x0805ae91 in main (argc=) at main.c:34
0x081e55d1	85	  return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest));

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

Aborted

(2) The application window closes, but the program apparently keeps running and requires a CTRL+C to exit.  Upon issuing the CTRL+C the following is printed to the terminal (Note, this could be the same problem as 471067, which we think might be IronPython's fault)

(/usr/lib/IPCE/ipy/ipy.exe:4710): GLib-CRITICAL **: g_hash_table_lookup: assertion `hash_table != NULL' failed
**
** ERROR:(object.c:1599):mono_class_create_runtime_vtable: assertion failed: (ret == 0)
Aborted

EXPECTED RESULTS

The program should exit cleanly with a 0 exit status.

COMMENTS
Comment 1 Brad Taylor 2009-04-14 19:08:02 UTC
Brian, can you reproduce this crash with MONO_UIA_BRIDGE=foo ?  It seems like more ironpython problems to me.
Comment 2 Brian Merrell 2009-06-30 20:46:28 UTC
Originally I thought I could reproduce this bug with MONO_UIA_BRIDGE=foo, however, I don't believe that is the case.  Previously I was simply running the following commands in succession from a terminal:

MONO_UIA_BRIDGE=foo
/home/a11y/code/uia2atk/test/sample/maskedtextbox.py

I noticed, however, that the maskedtextbox.py sample application was still accessible.  Then, I decided to set MONO_UIA_BRIDGE=foo in the /usr/bin/ipy script like this:

#!/bin/sh
MONO_UIA_BRIDGE exec /usr/bin/mono /usr/lib/IPCE/ipy/ipy.exe "$@"

After doing this, the sample application is no longer accessible and I can no longer reproduce this issue.
Comment 3 Brian Merrell 2009-06-30 20:52:48 UTC
(In reply to comment #2)
> 
> #!/bin/sh
> MONO_UIA_BRIDGE exec /usr/bin/mono /usr/lib/IPCE/ipy/ipy.exe "$@"
> 

Sorry, this should have read:

#!/bin/sh
MONO_UIA_BRIDGE=foo exec /usr/bin/mono /usr/lib/IPCE/ipy/ipy.exe "$@"
Comment 4 Brad Taylor 2009-07-14 14:24:36 UTC
For 

MONO_UIA_BRIDGE=foo
/home/a11y/code/uia2atk/test/sample/maskedtextbox.py

to work, you would need to "export MONO_UIA_BRIDGE=foo".  Otherwise:

MONO_UIA_BRIDGE=foo /home/a11y/code/uia2atk/test/sample/maskedtextbox.py

(e.g. on the same line) should also work.
Comment 5 Brad Taylor 2009-07-14 16:08:26 UTC
Move all P1 and P2 bugs into Release 1.1 milestone.