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)
----------------------------------------------------------------------
Message: 1
Date: Tue, 04 Jun 2019 18:18:09 +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-06-04 18:18
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-06-04 18:18 Updated by: comer352l
Comment:
Reply To keith
Reply To comer352l
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
Sure, but I don't see any specific requirements specification for C++
bindings ... in particular, no requirement for a selectLibrary() method.
That's right. These are no requirements, just the way I have choosen to go.
Implicit linking could also be used instead LoadLibrary/GetProcAddress/
reinterpret_cast.
But that means binding to a specific DLL/hardware, which is exactly the
opposite of what SAE-J2534 tries to reach.
And you usually don't get anything else than the DLL from a hardware
manufacturer (no header file etc.).
---------------------------------------------------------------------
Ticket Status:
Reporter: comer352l
Owner: (None)
Type: Issues
Status: Closed
Priority: 5 - Medium
MileStone: (None)
Component: (None)
Severity: 5 - Medium
Resolution: Invalid
---------------------------------------------------------------------
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: Tue, 04 Jun 2019 18:19:48 +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-06-04 18:19
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-06-04 18:19 Updated by: comer352l
Comment:
Reply To keith
Reply To comer352l
That's why the DLL association needs to be changed "on the fly".
By "on the fly", I mean ad-hoc, possibly any number of times after the
class instance has been created. I understand the need to support multiple
arbitrarily named DLLs, but surely any one class instance would need to
establish only one DLL association? Certainly, that's how I would implement
it ... a distinct class instance for each distinct DLL association, with
the DLL name, (or a registry selector for that name), passed as argument to
the constructor, and no method tempting a subsequent (potentially harmful)
change. But that's just my opinion; it's your application, so your choice.
Right, it's one DLL association per class instance.
A library selection method allows switching the DLL (the used hardware) without
re-creating an instance.
It's not that hard to implement. ;-)
---------------------------------------------------------------------
Ticket Status:
Reporter: comer352l
Owner: (None)
Type: Issues
Status: Closed
Priority: 5 - Medium
MileStone: (None)
Component: (None)
Severity: 5 - Medium
Resolution: Invalid
---------------------------------------------------------------------
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 4
*******************************************
