Transmission-QT 2.50 crashing Windows 7 x64

[jaspreet]

I apologize if this is the incorrect forum as I couldn't find a specific Transmission QT forum, but using the latest 2.50 build, getting a launch crash every time. Figured it was because I installed 2.5 on top of 2.42, so uninstalled 2.42 but still getting the same crash. Details below. Would be happy to post any additional logs/crash reports if I can.


Problem signature:
Problem Event Name: APPCRASH
Application Name: transmission-qt.exe
Application Version: 2.50.0.13228
Application Timestamp: 4f3f1f63
Fault Module Name: StackHash_0a9e
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Code: c0000005
Exception Offset: 00000000
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

[jaspreet]

Alright, went to /AppData/Local & /AppData/Roaming and deleted the transmission directories... this time, it did not crash for about a minute, then got the following crash


Problem signature:
Problem Event Name: APPCRASH
Application Name: transmission-qt.exe
Application Version: 2.50.0.13228
Application Timestamp: 4f3f1f63
Fault Module Name: msvcrt.dll
Fault Module Version: 7.0.7601.17744
Fault Module Timestamp: 4eeaf722
Exception Code: c0000005
Exception Offset: 000a061e
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

[jaspreet]

Alright, so upon further research, found the following solution at http://sourceforge.net/apps/wordpress/t ... -problems/

Crash the first time it is used, after a few (30) seconds. Workaround: when the Change Session panel opens, with Start Local Session selected, instead of hitting OK hit Cancel. The problem has been found and its fixed (locally) on version 2.30b1. It is not a bug on Transmission, its on miniupnp (patch sent upstream).


However, upon trying to change the settings, the program again crashes with the following


Problem signature:
Problem Event Name: APPCRASH
Application Name: transmission-qt.exe
Application Version: 2.50.0.13228
Application Timestamp: 4f3f1f63
Fault Module Name: msvcrt.dll
Fault Module Version: 7.0.7601.17744
Fault Module Timestamp: 4eeaf722
Exception Code: c0000005
Exception Offset: 000a061a
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

[rb07]

Download it again from SourceForge, the original build crashed if port forwarding was enabled, which is the default.

I re-build it and uploaded it to SourceForge about a day or two ago.

BTW the SourceForge project has its own forum. Transmission-Qt for Windows is an unofficial build, with some modifications.

For those interested in the technical details: Its a build problem, some times gcc produces bad code when optimization is enabled. In this case, which I've seen 3 times now, third-party/libnatpmp corrupts its call stack and crashes the program with an invalid access violation (the 0xc0000005 code above).

At first it looked like a bug in libnatpmp since the author did (still does) weird things to workaround the differences between Windows XP and older. I fixed that workaround, showed it in the forum, and the author didn't like it. My 'fix' made transmission work again with full optimization... but I was wrong, the problem came back about 3 months ago, a change of development computers made that disappear, then came back last week. This time I only disabled optimization in that library and everything works. Isn't development fun?

[jaspreet]

Unfortunately, as you can see, the one that you pointed me to as well as the one I originally downloaded (which was only about 30 minutes prior to this post) are one and the same. Are there any other logs or crash reports or debug versions that would help? Let me know, thanks!

[rb07]

Let's check one thing first: you picture shows the installer, what MD5 or SHA-1 do you have in the application?

I get: MD5 0f466627427c10bfa922c0e9d6e3eaeb

If we are talking about the same application then let's try some test:

Don't run the program yet.

See if you have the directory %APPDATA%/transmission; if you do, inside you should see the file settings.json, open it in an editor and find the line that says:

Code: Select all

    "port-forwarding-enabled": true,

change true to false, and save the file.

Now try running the application. I would be very surprised if the latest build had the same problem as before (at least one person reported that the problem was fixed), but I wouldn't if the installer somehow didn't overwrite the executable.

[jaspreet]

Same MD5, 0F466627427C10BFA922C0E9D6E3EAEB,

deleted the original 2.42 settings.json, opened Transmission, hit cancel instead of start local session, made one change to the preferences, saved, exited app, new settings.json created in %APPDATA%/transmission folder, changed "port-forwarding-enabled": true to "port-forwarding-enabled": false, upon restart of the program, crashed immediately after startup

with the following


Problem signature:
Problem Event Name: APPCRASH
Application Name: transmission-qt.exe
Application Version: 2.50.0.13228
Application Timestamp: 4f3f1f63
Fault Module Name: StackHash_0a9e
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Code: c0000005
Exception Offset: 00000000
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789


checked the setttings.json file again, for some reason, "port-forwarding-enabled": was set to true, opened the file in notepad with administrative privileges (not that it should make a difference), changed "port-forwarding-enabled":false and the program works!

[jaspreet]

However, I'm guessing this is the same setting that allows for UPnP, so, does this mean for the time being I need to manually forward the ports or is there a work around?

[rb07]

Port forwarding should be working, but there is something strange with your computer, I'm not sure what, it sounds like Windows or something else (security or anti-virus crap) is caching (making a copy of) the old executable... but I've never seen what you describe (it maybe happened also with settings.json, unless the program was still running, then it was normal -- the application saves settings.json when it exits, overwriting your changes).

From your last messages my conclusion is that you are running the previous build. I said "running", the file is fine by looking at the MD5, but the latest build (and I deleted the defective build from SF) doesn't crash for me (on 2 different computers), and it doesn't crash for at least one other person that reported it at the SF forum... and he also went from defective, which crashed, to last build.

BTW all those "Problem signature ..." don't help, please stop filling these messages with that Windows garbage.

[jaspreet]

As soon as I enable UPnP / port forwarding, the application crashes. Now, I'm not disputing what you're saying about having an "old" version of the file, but you state that you uploaded the latest build a

I re-build it and uploaded it to SourceForge about a day or two ago.

I downloaded 2.50 only earlier this morning so that has to mean that I have the latest build. Again, I can do without the port forwarding UPnP and just manually open the ports in my router, but would like to help to solve this problem if possible.

Also, could you direct me to the SourceForge Project forum?

BTW the SourceForge project has its own forum. Transmission-Qt for Windows is an unofficial build, with some modifications.

[rb07]

Again what you describe is known and was fixed. That's how the original problem behaved.

You don't need to download and install again and again, nothing different is going to happen. If the program has the same MD5 than the one I'm using, then they are the same and it is the latest build.

The old one has a MD5 of 4a856296ed748dd155d2a4971328076c2. Somehow, I don't know how, you seem to be running the old one. I just tested it again, the old one crashes, the new one doesn't. I also noticed that the installer leaves old, not needed, files around... could you see if you have a transmission-qt.exe.manifest along side the program? that's not needed anymore, delete it. I don't know if I made Windows believe that the old version and the new are the same, by using the same version number (the real manifest is embedded in the application).

The SF forum is Transmission-Qt for Win forums

[rb07]

There is another possibility: its a different crash.

It could be crashing somewhere else because, as I remember, this kind of crash first appeared to be in miniupnp, and currently in libnatpmp. Both libraries come from the same source (not code source, but author) so perhaps its crashing in jaspreet's case in miniupnp (which is still using optimization in the built application).

If anyone with this problem want to test this theory let me know, I'll upload an app with both libraries built with no optimization.

[blacke4dawn]

Wouldn't mind testing it myself, since it seems I'm having the same crash problems with 2.50.

[rb07]

blacke4dawn:

In the experimental folderI left a modified version 2.50, just the executable, replace the one you have installed and try it. The revision they report is different (in Help:About), the old one is 13228, the new one is 13236, but both are release version 2.50 and that's what they report to the tracker -- no experimental version).

The relevant difference is that both libnatpmp and miniupnp libraries are built with no optimization, the rest of the program uses the usual optimization.

I would appreciate if somebody reports the result of testing this version.

[blacke4dawn]

Revision 13236 has lasted several minutes now without crashing while 13228 crashed after 2 secs so already a huge improvement.

I'll keep you posted on how long it lasts since I'm having "random" crashes with 2.42 that I never checked up on (weeks, sometimes months apart).