Bug 321828 (MONO79116) - SIGSEGV using win32 FormatMessage API
Summary: SIGSEGV using win32 FormatMessage API
Status: RESOLVED MOVED
Alias: MONO79116
Product: Mono: Runtime
Classification: Mono
Component: interop (show other bugs)
Version: 1.1
Hardware: Other Other
: P3 - Medium : Normal
Target Milestone: ---
Assignee: Mono Bugs
QA Contact: Mono Bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-20 12:01 UTC by Gert Driesen
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
Zip file containing repro (5.73 KB, application/zip)
2006-08-20 12:08 UTC, Thomas Wiest
Details
test.cs (2.75 KB, text/plain)
2006-08-21 18:03 UTC, Thomas Wiest
Details
test2.cs (2.54 KB, text/plain)
2006-08-21 18:05 UTC, Thomas Wiest
Details

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


---- Reported by gert.driesen@pandora.be 2006-08-20 05:01:22 MST ----

I'm currently using the Win32 FormatMessage API to lookup messages from 
unmanaged resource DLLs, however there appear to be some issues with this.

First of all, the number of bytes returned by the FormatMessage API is 
different when executed from Mono, and is not consistent.

When executing the exact same call (see attached repro) numerous times I 
get results ranging from 6 to 14 bytes, while MS.NET always returns 10 
bytes.

Also when running it on Mono, I occasionally get a 234 win32 error, which 
means that more data is available. However, I'm explicitly letting the 
FormatMessage API allocate the buffer, so we should never get a 234 (and 
I actually don't get it when running on MS.NET).

Eventually, I always get a SIGSEGV:

To reproduce:

1. Extract the attached zip file.
2. Compile test.cs.
3. Run test.exe on Windows (as it uses win32 API calls).

The attached zip file contains:

- test.cs: C# source for reproducing error
- EventLogMessages.dll: unmanaged resource DLL.

Note: I've only tested using the Mono 1.1.6 release, as I have problems 
building Mono from SVN on Windows.

Expected result:

10
10
drieseng

(1000 times, as I execute the FormatMessage API in a loop)

The first number is the number of bytes read, while the second number is 
the length of the message (after converting from ptr to string).

Actual result:

14
8
drieseng
win32 error [234]: Some sort of w32 error occurred: 234

6
9
drieseng

18
8
drieseng
6
9
drieseng

win32 error [234]: Some sort of w32 error occurred: 234

6
9
drieseng

22
8
drieseng
6
9
drieseng

6
9
drieseng

6
9
drieseng

6
9
drieseng

6
9
drieseng

6
9
drieseng

6
9
drieseng

18
8
drieseng
9
8
drieseng
18
8
drieseng
6
9
drieseng

6
9
drieseng

9
8
drieseng
18
8
drieseng
9
8
drieseng
18
8
drieseng
6
9
drieseng

6
9
drieseng

6
9
drieseng

6
9
drieseng

6
9
drieseng

6
9
drieseng

6
9
drieseng

6
9
drieseng


=================================================================
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.
=================================================================

Stacktrace:

  at (wrapper managed-to-native) 
ConsoleApplication1.Program.FormatMessage 
(ConsoleApplication1.Program/FormatMessageFlags,intptr,uint,int,intptr&,in
t,intptr[]) <0x00004>
  at (wrapper managed-to-native) 
ConsoleApplication1.Program.FormatMessage 
(ConsoleApplication1.Program/FormatMessageFlags,intptr,uint,int,intptr&,in
t,intptr[]) <0xffffffff>
  at ConsoleApplication1.Program.FormatMessage (string,uint,string[]) 
<0x000d9>
  at ConsoleApplication1.Program.Main (string[]) <0x00053>
  at (wrapper runtime-invoke) System.Object.runtime_invoke_void_string[] 
(object,intptr,intptr,intptr) <0xffffffff>

This application has requested the Runtime to terminate it in an unusual 
way.
Please contact the application's support team for more information.



---- Additional Comments From gert.driesen@pandora.be 2006-08-20 05:08:47 MST ----

Created an attachment (id=170275)
Zip file containing repro




---- Additional Comments From robertj@gmx.net 2006-08-21 11:02:53 MST ----

This is a problem of PtrToStringAuto. The attached
version uses the ANSI version and it works.





---- Additional Comments From robertj@gmx.net 2006-08-21 11:03:33 MST ----

Created an attachment (id=170276)
test.cs




---- Additional Comments From robertj@gmx.net 2006-08-21 11:05:15 MST ----

I'm attaching an slightly "optimized" p/invoke variant.




---- Additional Comments From robertj@gmx.net 2006-08-21 11:05:39 MST ----

Created an attachment (id=170277)
test2.cs




---- Additional Comments From gert.driesen@pandora.be 2006-08-21 11:25:35 MST ----

It's probably the PtrToStringAuto and StringToHGlobalAuto issue (https://bugzilla.novell.com/show_bug.cgi?id=MONO79117) that is also causing this SIGSEGV, and not just an issue in 
PtrToStringAuto alone. The number of bytes returned by FormatMessage 
is not consistent and that is before PtrToStringAuto gets involved.



---- Additional Comments From robertj@gmx.net 2006-08-21 12:33:56 MST ----

Both versions of test.cs that I've uploaded report

10
10
drieseng

like MS.NET.

The problem is a discrepancy between DllImport.CharSet = CharSet.Xyz
and PtrToStringXyz ().

Using of pairwise explicit Ansi or Unicode fix the problem.




---- Additional Comments From gert.driesen@pandora.be 2006-08-26 11:12:53 MST ----

The patch for https://bugzilla.novell.com/show_bug.cgi?id=MONO79117 also fixes the random SIGSEGV's.

*** This bug has been marked as a duplicate of https://bugzilla.novell.com/show_bug.cgi?id=MONO79117 ***

Imported an attachment (id=170275)
Imported an attachment (id=170276)
Imported an attachment (id=170277)

Unknown operating system unknown. Setting to default OS "Other".
This bug was marked DUPLICATE in the database it was moved from.
    Changing resolution to "MOVED"