Re: [Mingw-users] SNFMulti.DLL -- C++ test app SIGSEGV in mingwm10.dll

[Pete M. <mad...@mi...>]

Rüdiger Ranft wrote:

<snip/>
> Have you tried to rebuild *all* of your libs+application?

That was the first thing I did actually. Since I was working from a new 
install of Code::Blocks + MinGW I wanted to be sure everything was up to 
date. Also, we've switched to a new paradigm for managing this project 
using SVN and a collection of separate sub-projects represented as 
external references to the SDK distribution project...

Suffice to say, a lot was new: So, the first successful build was a 
complete rebuild with a new project.

>  One source for
> this error is when some Interface between the binaries changes slighly
> (not enough to get linker errors but enough to crash) and make did'nt
> catch to rebuild all affected parts. 

This may be important (see below).

> Do you have other libraries in your
> project, which depend on different C libraries (cygwin, VS-*)?
>   

Winsock2 (libws2_32.a)

Everything else (aside from default libs) was created in-house and in 
this case compiled from source.

===

(apologies in advance for the length - I think/hope the content will be 
useful to others)

I _may have_ solved this problem -- I'm not sure yet. I will know when 
I've successfully built and tested the new snfmulti.dll.

It appears that the problem was with mingwm10.dll itself - or rather, 
the version I was using.

First -- I didn't realize there were multiple versions of it. Up to now 
I'd never had a problem and when comparing copies from different 
installs of MinGW mingwm10.dll had always been the same. In fact it 
appeared whenever I had looked that the file had not changed in a very 
long time... apparently just my luck or lack of attention.

I was following the advice to "use a newer gdb 6.8.3" and thought (for 
many reasons) that the easiest/safest way to do that would be to install 
MinGW from sourceforge in it's desired location C:\MinGW. Code::Blocks + 
MinGW installer puts it under "Program Files" with itself -- something I 
discovered is an explicit no-no according to the How-To Install MinGW 
part of the site.

Side Note: The newer debugger gave even less information than the one I 
had installed with Code::Blocks + MinGW -- All of the file / function 
references disappeared from the stack trace! I would like to understand 
better why that is the case. I was surprised because I was expecting 
more/better information, not less. If I did (or failed to do) something 
to cause this I would like to learn about that.

Out of frustration and curiosity I pointed Code::Blocks at the new MinGW 
install and rebuilt the entire project. Stil no joy-- but this process 
started me looking closer at the MinGW install to make sure I wasn't 
missing pieces somewhere and that is when I discovered that the date and 
size were different on mingwm10.dll --- I dropped in the new version 
from the fresh install and the test app fired up without a problem!

I presume that somewhere in my effort I copied an incompatible version 
of mingwm10.dll into the application's test directory and that is when 
it broke. I didn't think to look at that because I was stuck in a 
paradigm with the following erroneous assumptions:

* mingwm10.dll never changes and I did not change it (not a factor)
* I've made changes to the code (most likely I broke something weird the 
compiler didn't catch)
* I've made changes to the build options (most likely broke something in 
the setup that I didn't see)

So I kept running around that track trying to figure out what I broke in 
the code or the build options.

===

This raises a new question that has been asked before (based on google 
searches) and not quite answered sufficiently:

What do I do about the mingwm10.dll problem?

* I missed that there was a possibility of version conflicts. Others may 
also.

* I have a customer base that has a possibly incompatible version of 
mingwm10.dll already and it may get mixed up with the new SDK in the 
field. I expect developers/OEMs to handle this well, but what about 
their customers? What about our customers who have existing SNF apps 
with various mingwm10.dll versions floating around?

* There does not appear to be a way to do away with mingwm10.dll -- it 
must go along with the SNF apps and SDK. Is there a practical way to 
remove this requirement or integrate the functionality with our apps/SDK 
so that there is no possibility of confusion in the field? (For now I 
guess documentation will have to do).

* It is not certain yet that mingwm10.dll version conflicts are the 
issue. It is possible that some older versions may work ok, or may work 
in some cases... This makes the picture a bit more complex -- though the 
solution is the same: be sure that the correct version is used with the 
correct version of our apps/SDK -- However, that may be a problem... 
Customers of all types do not upgrade all at once-- and many may have 
multiple versions in production. If they get those mixed up in some way 
then sorting out which is which will be trouble for them and for us 
either forcing a system wide upgrade (in some cases many hundreds of 
servers) or some magical (as yet undefined) process for figuring out 
which mingwm10.dll goes with which instance of the app.

Any thoughts or comments welcome,

Once I'm sure I can run the new snfmulti.dll and test app using the new 
mingwm10.dll I will post again so folks know this got solved.

Thanks,

_M