Send MinGW-Notify mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.osdn.me/mailman/listinfo/mingw-notify
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of MinGW-Notify digest..."
Please do not reply to this notification; the sender address is unable to
accept incoming e-mail. If you wish to unsubscribe you can do so at
https://lists.osdn.me/mailman/listinfo/mingw-notify.
Today's Topics:
1. [mingw] #39268: g++ -O1 produces crashing code when accessing
dlls via LoadLibrary()/GetProcAddress()/reinterpret_cast
(MinGW Notification List)
2. [mingw] #39268: g++ -O1 produces crashing code when accessing
dlls via LoadLibrary()/GetProcAddress()/reinterpret_cast
(MinGW Notification List)
3. [mingw] #39268: g++ -O1 produces crashing code when accessing
dlls via LoadLibrary()/GetProcAddress()/reinterpret_cast
(MinGW Notification List)
4. [mingw] #39268: g++ -O1 produces crashing code when accessing
dlls via LoadLibrary()/GetProcAddress()/reinterpret_cast
(MinGW Notification List)
5. [mingw] #39268: g++ -O1 produces crashing code when accessing
dlls via LoadLibrary()/GetProcAddress()/reinterpret_cast
(MinGW Notification List)
----------------------------------------------------------------------
Message: 1
Date: Fri, 31 May 2019 08:28:37 +0100
From: MinGW Notification List <[email protected]>
To: OSDN Ticket System <[email protected]>
Subject: [MinGW-Notify] [mingw] #39268: g++ -O1 produces crashing code
when accessing dlls via
LoadLibrary()/GetProcAddress()/reinterpret_cast
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
#39268: g++ -O1 produces crashing code when accessing dlls via
LoadLibrary()/GetProcAddress()/reinterpret_cast
Open Date: 2019-05-30 18:26
Last Update: 2019-05-31 08:28
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/39268
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39268
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2019-05-31 08:28 Updated by: keith
Comment:
Reply To comer352l
Reply To keith
Do please note that your c0000005 exception code is a SEGFAULT,
("access violation" in Microsoft parlance). This means that your
program is attempting to access memory to which it does not have access
rights. Likely causes are references to an uninitialized pointer, or to
memory which has already been deallocated; usually these are the result
of errors in the user program code, but unless you do provide a fully
self-contained test case, I am not willing to investigate further.
I know. But I'm pretty sure the code is correct.
More serious than the oddity I noted yesterday, this is wrong:
1. bool J2534_API::selectLibrary(std::string libPath)
2. {
3. FreeLibrary( _J2534LIB );
4. _J2534LIB = LoadLibraryA( libPath.c_str() );
5. ...
6. }
Your J2534_API class constructor initializes its _J2534LIB private member
variable to NULL; you then invoke its selectLibrary() method, which immediately
calls FreeLibrary() on that NULL pointer. Microsoft's documentation for
FreeLibrary() says that its argument must be a module handle, as returned by
either LoadLibrary(), or GetModuleHandle(), (or one of their derivatives); it
does not say that NULL is an acceptable value, so that's a potential SEGFAULT
staring you right in the face — dereference of a NULL pointer is, perhaps, the
most common cause of a SEGFAULT exception. (Even if FreeLibrary() does handle
the NULL pointer gracefully, such that the call becomes a no-op, the behaviour
is undocumented, and it is wrong for your code to depend on it.)
---------------------------------------------------------------------
Ticket Status:
Reporter: comer352l
Owner: (None)
Type: Issues
Status: Open
Priority: 5 - Medium
MileStone: (None)
Component: (None)
Severity: 5 - Medium
Resolution: None
---------------------------------------------------------------------
Ticket details:
I'm investigating the following crash, which occurs when accessing a dll via
LoadLibrary(), getProcAddress(), reinterpret_cast:
Problem signature:
Problem Event Name: BEX
Application Name: test.exe
...
Fault Module Name: StackHash_0a9e
...
Exception Offset: 0028fe9c
Exception Code: c0000005
Exception Data: badc0de1
...
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
The code only crashes if it is compiled with -O1 (-O2, ...).
Moving around pieces of the code seems to fix the issue.
I was finally able to create some reduced example code with working / non
working variants (attachment follows).
--
Ticket information of MinGW - Minimalist GNU for Windows project
MinGW - Minimalist GNU for Windows Project is hosted on OSDN
Project URL: https://osdn.net/projects/mingw/
OSDN: https://osdn.net
URL for this Ticket:
https://osdn.net/projects/mingw/ticket/39268
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39268
------------------------------
Message: 2
Date: Fri, 31 May 2019 08:51:46 +0100
From: MinGW Notification List <[email protected]>
To: OSDN Ticket System <[email protected]>
Subject: [MinGW-Notify] [mingw] #39268: g++ -O1 produces crashing code
when accessing dlls via
LoadLibrary()/GetProcAddress()/reinterpret_cast
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
#39268: g++ -O1 produces crashing code when accessing dlls via
LoadLibrary()/GetProcAddress()/reinterpret_cast
Open Date: 2019-05-30 18:26
Last Update: 2019-05-31 08:51
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/39268
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39268
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2019-05-31 08:51 Updated by: keith
Comment:
Reply To keith
Your J2534_API class constructor initializes its _J2534LIB private member
variable to NULL; you then invoke its selectLibrary() method ...
BTW, do you really need the selectLibrary() method anyway? I don't know your
requirements specification, but the ability to arbitrarily change the DLL
association of a J2534_API class instance, "on the fly", seems unusual. If you
don't explicitly need such a capability, why not bind the DLL within the
constructor itself, either using a name passed as a constructor argument, or
using a fixed name specified within the constructor code?
---------------------------------------------------------------------
Ticket Status:
Reporter: comer352l
Owner: (None)
Type: Issues
Status: Open
Priority: 5 - Medium
MileStone: (None)
Component: (None)
Severity: 5 - Medium
Resolution: None
---------------------------------------------------------------------
Ticket details:
I'm investigating the following crash, which occurs when accessing a dll via
LoadLibrary(), getProcAddress(), reinterpret_cast:
Problem signature:
Problem Event Name: BEX
Application Name: test.exe
...
Fault Module Name: StackHash_0a9e
...
Exception Offset: 0028fe9c
Exception Code: c0000005
Exception Data: badc0de1
...
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
The code only crashes if it is compiled with -O1 (-O2, ...).
Moving around pieces of the code seems to fix the issue.
I was finally able to create some reduced example code with working / non
working variants (attachment follows).
--
Ticket information of MinGW - Minimalist GNU for Windows project
MinGW - Minimalist GNU for Windows Project is hosted on OSDN
Project URL: https://osdn.net/projects/mingw/
OSDN: https://osdn.net
URL for this Ticket:
https://osdn.net/projects/mingw/ticket/39268
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39268
------------------------------
Message: 3
Date: Fri, 31 May 2019 13:22:40 +0200
From: MinGW Notification List <[email protected]>
To: OSDN Ticket System <[email protected]>
Subject: [MinGW-Notify] [mingw] #39268: g++ -O1 produces crashing code
when accessing dlls via
LoadLibrary()/GetProcAddress()/reinterpret_cast
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
#39268: g++ -O1 produces crashing code when accessing dlls via
LoadLibrary()/GetProcAddress()/reinterpret_cast
Open Date: 2019-05-30 19:26
Last Update: 2019-05-31 13:22
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/39268
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39268
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2019-05-31 13:22 Updated by: comer352l
Comment:
Thank you very much for your comments.
I think I've finally found the reason for the crashes:
The compiler needs to know the calling convention, which is WINAPI alias
__stdcall in this case.
Afte adding it to the function prototypes, everything works fine again.
Sure, if the compiler uses the wrong calling convention, the stack doesn't get
managed correctly.
I just wonder why it has been been working fine without __stdcall for 10+ years
(and apparently still works fine without -O1).
---------------------------------------------------------------------
Ticket Status:
Reporter: comer352l
Owner: (None)
Type: Issues
Status: Open
Priority: 5 - Medium
MileStone: (None)
Component: (None)
Severity: 5 - Medium
Resolution: None
---------------------------------------------------------------------
Ticket details:
I'm investigating the following crash, which occurs when accessing a dll via
LoadLibrary(), getProcAddress(), reinterpret_cast:
Problem signature:
Problem Event Name: BEX
Application Name: test.exe
...
Fault Module Name: StackHash_0a9e
...
Exception Offset: 0028fe9c
Exception Code: c0000005
Exception Data: badc0de1
...
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
The code only crashes if it is compiled with -O1 (-O2, ...).
Moving around pieces of the code seems to fix the issue.
I was finally able to create some reduced example code with working / non
working variants (attachment follows).
--
Ticket information of MinGW - Minimalist GNU for Windows project
MinGW - Minimalist GNU for Windows Project is hosted on OSDN
Project URL: https://osdn.net/projects/mingw/
OSDN: https://osdn.net
URL for this Ticket:
https://osdn.net/projects/mingw/ticket/39268
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39268
------------------------------
Message: 4
Date: Fri, 31 May 2019 12:27:53 +0100
From: MinGW Notification List <[email protected]>
To: OSDN Ticket System <[email protected]>
Subject: [MinGW-Notify] [mingw] #39268: g++ -O1 produces crashing code
when accessing dlls via
LoadLibrary()/GetProcAddress()/reinterpret_cast
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
#39268: g++ -O1 produces crashing code when accessing dlls via
LoadLibrary()/GetProcAddress()/reinterpret_cast
Open Date: 2019-05-30 18:26
Last Update: 2019-05-31 12:27
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/39268
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39268
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2019-05-31 12:27 Updated by: keith
Comment:
Reply To keith
Reply To comer352l
What's the maximum attachment size ?
I don't know; it doesn't appear to be mentioned in the documentation, so
I've submitted a technical query to ask.
Prompted by my enquiry, OSDN.net have now raised the attachment size limit to
10MB; (they haven't said what it was originally). They also admit that they
believe even 10MB is too small, so will work towards increasing it further, to
some new (unspecified) limit.
---------------------------------------------------------------------
Ticket Status:
Reporter: comer352l
Owner: (None)
Type: Issues
Status: Open
Priority: 5 - Medium
MileStone: (None)
Component: (None)
Severity: 5 - Medium
Resolution: None
---------------------------------------------------------------------
Ticket details:
I'm investigating the following crash, which occurs when accessing a dll via
LoadLibrary(), getProcAddress(), reinterpret_cast:
Problem signature:
Problem Event Name: BEX
Application Name: test.exe
...
Fault Module Name: StackHash_0a9e
...
Exception Offset: 0028fe9c
Exception Code: c0000005
Exception Data: badc0de1
...
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
The code only crashes if it is compiled with -O1 (-O2, ...).
Moving around pieces of the code seems to fix the issue.
I was finally able to create some reduced example code with working / non
working variants (attachment follows).
--
Ticket information of MinGW - Minimalist GNU for Windows project
MinGW - Minimalist GNU for Windows Project is hosted on OSDN
Project URL: https://osdn.net/projects/mingw/
OSDN: https://osdn.net
URL for this Ticket:
https://osdn.net/projects/mingw/ticket/39268
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39268
------------------------------
Message: 5
Date: Fri, 31 May 2019 13:46:08 +0200
From: MinGW Notification List <[email protected]>
To: OSDN Ticket System <[email protected]>
Subject: [MinGW-Notify] [mingw] #39268: g++ -O1 produces crashing code
when accessing dlls via
LoadLibrary()/GetProcAddress()/reinterpret_cast
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
#39268: g++ -O1 produces crashing code when accessing dlls via
LoadLibrary()/GetProcAddress()/reinterpret_cast
Open Date: 2019-05-30 19:26
Last Update: 2019-05-31 13:46
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/39268
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39268
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2019-05-31 13:46 Updated by: comer352l
Comment:
Reply To keith
BTW, do you really need the selectLibrary() method anyway? I don't know
your requirements specification, but the ability to arbitrarily change the
DLL association of a J2534_API class instance, "on the fly", seems unusual.
If you don't explicitly need such a capability, why not bind the DLL within
the constructor itself, either using a name passed as a constructor
argument, or using a fixed name specified within the constructor code?
Background:
The code is about accessing SAE-J2534-compliant dlls.
SAE-J2534 specifies an unified interface for accessing different automotive
hardware (interfaces for diagnostic purposes, firmware flashing etc.) via a
proprietary dlls.
The spec defines function prototypes, arguments and return values and the
behavior of the functions, the implementation is up to the equipment
manufaturers.
It also defines a method to register/find J2534-compliant dlls using the
Windows registry.
See http://www.drewtech.com/support/passthru.html
That's why the DLL association needs to be changed "on the fly".
---------------------------------------------------------------------
Ticket Status:
Reporter: comer352l
Owner: (None)
Type: Issues
Status: Open
Priority: 5 - Medium
MileStone: (None)
Component: (None)
Severity: 5 - Medium
Resolution: None
---------------------------------------------------------------------
Ticket details:
I'm investigating the following crash, which occurs when accessing a dll via
LoadLibrary(), getProcAddress(), reinterpret_cast:
Problem signature:
Problem Event Name: BEX
Application Name: test.exe
...
Fault Module Name: StackHash_0a9e
...
Exception Offset: 0028fe9c
Exception Code: c0000005
Exception Data: badc0de1
...
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
The code only crashes if it is compiled with -O1 (-O2, ...).
Moving around pieces of the code seems to fix the issue.
I was finally able to create some reduced example code with working / non
working variants (attachment follows).
--
Ticket information of MinGW - Minimalist GNU for Windows project
MinGW - Minimalist GNU for Windows Project is hosted on OSDN
Project URL: https://osdn.net/projects/mingw/
OSDN: https://osdn.net
URL for this Ticket:
https://osdn.net/projects/mingw/ticket/39268
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39268
------------------------------
Subject: Digest Footer
_______________________________________________
MinGW-Notify mailing list
[email protected]
https://lists.osdn.me/mailman/listinfo/mingw-notify
------------------------------
End of MinGW-Notify Digest, Vol 21, Issue 1
*******************************************
