MinGW - Minimalist GNU for Windows

Fork

• mingw-dist
• build-aux
• wtklite
• pexports
• website
• mingw-get
• mingw-org-wsl
• mingw-pkgspecs

Donation

Unfortunately, the dll I'm using in the example code is too large to attach it (1.7MB).
Should work with any other dll (adjusting dll name, function names and prototypes).

Tested operating Systems: Windows 7 64bit, Windows XP 32bit
Tested MinGW versions:
MinGW/gcc 4.8.2 (i686-posix-dwarf-rev3, Built by MinGW-W64 project)
MinGW/gcc 7.3.0 (i686-posix-dwarf-rev0, Built by MinGW-W64 project)

Reply To comer352l

Unfortunately, the dll I'm using in the example code is too large to attach it (1.7MB).

Hmm. I was just about to ask where that DLL originates.

Should work with any other dll (adjusting dll name, function names and prototypes).

Well, if you want us to investigate, you really need to provide a fully self-contained test case. Don't expect us to work around your omissions — you need to either:­–

• adapt your test case, to work with one of the system DLLs, or
• provide a reduced sample DLL — ideally in source form — within your test case, on which it operates.

Reply To comer352l

Tested operating Systems: Windows 7 64bit, Windows XP 32bit
Tested MinGW versions:
MinGW/gcc 4.8.2 (i686-posix-dwarf-rev3, Built by MinGW-W64 project)
MinGW/gcc 7.3.0 (i686-posix-dwarf-rev0, Built by MinGW-W64 project)

Products from the MinGW-W64 project — a project which gratuitously (and illegally) infringes our registered trademark — do not originate, and are not supported here. Notwithstanding, if you can provide a self-contained test case, I'd be interested to see if the same problem is reproduced with our official MinGW compiler suite.

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.

Reply To keith

Reply To comer352l Well, if you want us to investigate, you really need to provide a fully self-contained test case. Don't expect us to work around your omissions — you need to either:­–

Sure, I'm working on it.

* adapt your test case, to work with one of the system DLLs, or

Any suggestions ? Windows is not my "native" environment...

What's the maximum attachment size ?

Reply To keith

Reply To comer352l Products from the MinGW-W64 project — a project which gratuitously (and illegally) infringes our registered trademark — do not originate, and are not supported here.

I didn't know that, sorry.
I was just testing with the versions that came with Qt4/5.
I'll go and switch over to the original.

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.

Reply To comer352l

Reply To keith

Reply To comer352l Well, if you want us to investigate, you really need to provide a fully self-contained test case. Don't expect us to work around your omissions — you need to either:­–

Sure, I'm working on it.

* adapt your test case, to work with one of the system DLLs, or

Any suggestions ? Windows is not my "native" environment...

Any of the system DLLs, which is not linked by default; I've used psapi.dll, in the past: see https://osdn.net/projects/mingw/scm/git/mingw-org-wsl/blobs/5.2-trunk/mingwrt/mingwex/dlfcn.c

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.

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.

Hmm. I'm not so sure. At a first quick glance, this looks odd:

 extern "C" {
         #include "windows.h"
 }

• Firstly, (although GCC will tolerate it), the # introducing the include directive really should not be anywhere other than in column one.
• Secondly, why use iquote semantics for "windows.h"? Is this the system <windows.h>, or your own project-local header? (If the latter, then I would suggest that the name is extremely badly chosen, because it conflicts with the system header name).
• Thirdly, you should not embed the #include directive within the extern "C" block scope; that scope should be correctly specified within the included header itself, (and, in this case if it is the system's <windows.h> which is being included, then this is certainly taken care of, because it is a C++ compatible C header).

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:

 bool J2534_API::selectLibrary(std::string libPath)
 {
         FreeLibrary( _J2534LIB );
         _J2534LIB = LoadLibraryA( libPath.c_str() );
         ...
 }

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

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?

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.
After 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).

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.

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

After reading a bit more about calling conventions and the GNU compiler specifics, I think I can't blame the compiler for doing anything wrong here.
Looks like __stdcall has always been needed and it was just *BIG* luck that it has been working fine without it for such a long time.
So I'm revoking this bug report, sorry for the noise.