[Mono-dev] .net winforms and windows

Wed Jun 13 22:50:30 UTC 2012

Before reading further, i wanted to ask: Is it a good idea for me to 
pull in upstream changes with git while i have pending commits to 
eventually possibly be merged upstream?  I'd like to see if some of my 
below errors have been fixed.

--
Running mono on my test, if i replace the Invoke (which occasionally 
failed) with a direct close, it seems to go a lot further without 
occasionally failing on repeated re-runs...  I don't (or haven't yet) 
get a failure on invoke since i did that...

So, invoke needs to be troubleshot.

But i still found 2 failures in gdb also seemingly unrelated to my patch 
which happenned on my test code once every so many runs, and for now 
this is holding me up from re-opening my pull request.  There's probably 
no rush anyway.

from running within gdb  ('gdb mono' 'run FormEventTest.exe' repeat 2nd 
step until failure, run 'bt' for stacktrace)

One was the 'gdi+ object busy' I mentioned...  This seems to only happen 
when i replace the Invoke with a direct close().

The other looks like an issue with the jit compiler in Windows when 
calling strchr() (a standard c function) :  SIGSEGV (Segmentation fault) 
from:
#0  0x7655dc12 in strchr () from /cygdrive/c/Windows/syswow64/msvcrt.dll
#1  0x003a8b88 in ?? ()
#2  0x65b166b0 in mono_mb_emit_exception_full (mb=0x3053b08,
     exc_nspace=<incomplete type>, exc_name=<incomplete type>,
     msg=<incomplete type>) at method-builder.c:511
#3  0x65b16798 in mono_mb_emit_exception (mb=0x3053b08,
     exc_name=<incomplete type>, msg=<incomplete type>) at 
method-builder.c:528
#4  0x65affa25 in mono_marshal_get_native_wrapper (method=0x3089278,
     check_exceptions=1, aot=0) at marshal.c:8489
#5  0x659f23d4 in mono_method_to_ir (cfg=0x302bcb8, method=0x3089180,
     start_bblock=0x3071ba0, end_bblock=0x3071c50, return_var=0x0,
     dont_inline=0x3037f28, inline_args=0x0, inline_offset=0, 
is_virtual_call=0)
     at method-to-ir.c:6812
#6  0x659c98e2 in mini_method_compile (method=0x3089180, opts=59861503,
     domain=0x374e60, run_cctors=1, compile_aot=0, parts=0) at mini.c:4548
#7  0x659caf2e in mono_jit_compile_method_with_opt (method=0x3089180,
     opt=59861503, ex=0x28f8b0) at mini.c:5253
#8  0x659cb6c2 in mono_jit_compile_method (method=0x3089180) at mini.c:5535
#9  0x65a58eaa in common_call_trampoline (regs=0x28f998,
     code=0x2748988 "\203\304 \311", <incomplete sequence \303>, 
m=0x3089180,
     tramp=0x0, vt=0x0, vtable_slot=0x0, need_rgctx_tramp=0)
     at mini-trampolines.c:483
#10 0x65a59616 in mono_magic_trampoline (regs=0x28f998,
---Type <return> to continue, or q <return> to quit---
     code=0x2748988 "\203\304 \311", <incomplete sequence \303>, 
arg=0x3089180,
     tramp=0x0) at mini-trampolines.c:589
#11 0x00540066 in ?? ()
#12 0x0274895f in ?? ()
#13 0x02746c48 in ?? ()
#14 0x0274603c in ?? ()
#15 0x02745bc8 in ?? ()
#16 0x027111d4 in ?? ()
#17 0x02710d76 in ?? ()
#18 0x659cb7ac in mono_jit_runtime_invoke (method=0x3a8338, obj=0x0,
     params=0x28fc38, exc=0x0) at mini.c:5897
#19 0x65b235d2 in mono_runtime_invoke (method=0x3a8338, obj=0x0,
     params=0x28fc38, exc=0x0) at object.c:2809
#20 0x65b25d92 in mono_runtime_exec_main (method=0x3a8338, args=0x379e00,
     exc=0x0) at object.c:4007
#21 0x65a2f082 in mono_main (argc=2, argv=0x3a2f90) at driver.c:1013
#22 0x004014bd in main () at main.c:91

Opinions welcome on whether or not i should re-open my pull request, 
because (1) These are unrelated to my patch, but (2) these are related 
to my unit test.

On 06/13/2012 05:45 PM, Stifu wrote:
> "My test code (attached) runs fine in Windows .net, doesn't crash once, and i
> just ran it from the command prompt about 30-40 times in a row in .net.  So
> that should run in mono, no?"
>
> Yes, I was just confused by your original post: "In my testing of .net
> winforms on windows i received a lot of gdi+ object busy errors", which made
> it sound like the errors were .NET ones.
>
>
> Rob Wilkens wrote
>> [long story short: Got to troubleshoot some more, but the answer is that
>> these apps are functional in windows, attached a sample]
>>
>> In Windows.NET it definitely works, both the code sample from the bug
>> report (which, incidentally, is not running for me right now, so i've
>> pulled back my pull request while i investigate, if i figure out why i
>> will reopen it, i haven't troubleshot that yet)..  My test code
>> (attached) runs fine in Windows .net, doesn't crash once, and i just ran
>> it from the command prompt about 30-40 times in a row in .net.  So that
>> should run in mono, no?
>>
>> In unpatched mono in windows, my code leaves two windows open, and after
>> you close that it will say 'error' because the would-be assertions fail.
>>
>> In mono with my patch, it passed, but it crashed every 5-10 runs,
>> unrelated, i beleive, to my patch but more to the rest of the code now
>> being run because of the patch.  Yesterday i was getting GDI+ Object
>> Busy, I can't reproduce that now, but that could be any number of things
>> such as timing.
>>
>> The crash I'm occasionally getting in my app now may have something to
>> do with the change in response to your message yesterday about needing
>> to call invoke (the form was created in thread 1, invoke is being called
>> in thread 3[the 2nd thread]).  But the form was shown with a call to
>> Application.Run(form2) in thread 2, because i couldn't figure another
>> easy way to make the application.run loop to exit on its own at the end
>> of execution (I tried several methods, none worked).
>>
>> The crash I've traced twice to here (again in Windows .NET this does not
>> crash) using gdb:..
>> #8  0x02733612 in ?? ()
>> #9  0x027333c1 in ?? ()
>> #10 0x659cb7ac in mono_jit_runtime_invoke (method=0x5bee70, obj=0x2f709d8,
>>       params=0x393ff44, exc=0x0) at mini.c:5897
>> #11 0x65b235d2 in mono_runtime_invoke (method=0x5bee70, obj=0x2f709d8,
>>       params=0x393ff44, exc=0x0) at object.c:2809
>> #12 0x65b24237 in mono_runtime_delegate_invoke (delegate=0x2f709d8,
>>       params=0x393ff44, exc=0x0) at object.c:3489
>> #13 0x65b4ef76 in start_wrapper (data=0x2ff3d68) at threads.c:577
>> #14 0x65b7452a in inner_start_thread (arg=0x2ff3990)
>>     at mono-threads-windows.c:86
>> #15 0x7670339a in KERNEL32!BaseCleanupAppcompatCacheSupport ()
>>      from /cygdrive/c/Windows/syswow64/kernel32.dll
>> #16 0x02ff3990 in ?? ()
>> #17 0x770f9ef2 in ntdll!RtlpNtSetValueKey ()
>> ---Type<return>  to continue, or q<return>  to quit---ls ~
>>      from /cygdrive/c/Windows/system32/ntdll.dll
>> #18 0x02ff3990 in ?? ()
>> #19 0x770f9ec5 in ntdll!RtlpNtSetValueKey ()
>>      from /cygdrive/c/Windows/system32/ntdll.dll
>> #20 0x65b744e0 in mono_threads_platform_free ()
>>      from
>> /cygdrive/c/cygwin/home/RobWilkens/new-mono-local/bin/mono-2.0.dll
>>
>> But again, this doesn't seem to crash every or most times, and is
>> unrelated to my patch, only to my test.
>>
>> And i still have to first debug the original sample code..
>>
>> I'll try to make sure my code sample and the sample from the bug report
>> work before i re-open my pull request.  Both run fine on Windows 7 with
>> MS .NET.
>>
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at .ximian
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
> --
> View this message in context: http://mono.1490590.n4.nabble.com/net-winforms-and-windows-tp4649922p4649928.html
> Sent from the Mono - Dev mailing list archive at Nabble.com.
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list