client_test.exe crashes

[GoogleCodeExporter]

I currently test Snappy driver Installer that use you libtorrent Library
I have an error when I want to download on my Win8.1 x64 and also on a Win7 
x64. 
I posted a bugreport there: 
http://code.google.com/p/snappy-driver-installer/issues/detail?id=30

I also try client_test.exesend by BadPointer0

BadPointer0 setup:
libtorrent 1.0.3
BOOST 1.57.0
GCC 4.8.1 (MinGW)
<link>static <runtime-link>static <threading>multi <boost>source 
<boost-link>static <optimization>space <deprecated-functions>off <rtti>off 
<geoip>off <asserts>production <debug-symbols>off <iconv>off <i2p>off <ipv6>off

I do not know much, I'm not a developer but I can do some tests, if needed.

Original issue reported on code.google.com by Mateo.RO...@gmail.com on 17 Mar 2015 at 1:35

[GoogleCodeExporter]

just saying that it crashes won't help me figure out why. do you have any 
information at all about where it crashes?

say, a stack trace at least. Do you know why the developers of 
snappy-driver-installer believe this is a bug in libtorrent?

Original comment by arvid.no...@gmail.com on 18 Mar 2015 at 1:38

[GoogleCodeExporter]

do you have a .torrent file that reproduces the crash?

Original comment by arvid.no...@gmail.com on 18 Mar 2015 at 1:38

[GoogleCodeExporter]

client_test.exe is your example program from libtorrent-rasterbar-1.0.3.tar.
The torrent can be found at http://driveroff.net/SDI_Update.torrent but I think 
it's irrelevant to the issue.

Thousands of people are using Snappy Driver Installer and no one reported about 
this issue before. It must be something specific to this particular PC. I guess 
we have to work with the end user and try to gather enough information to find 
out why it happens but I don't know which facilities libtorrent has for 
debugging crashes.

Snappy Driver Installer creates a backtrace.txt file when crashes but in this 
case nothing is created. The latest messages from libtorrent are:
Torrent: dht_reply_alert | SDI_Update () received DHT peers: 61
Torrent: dht_reply_alert | SDI_Update () received DHT peers: 81
Torrent: dht_
[cut off]
Snappy Driver Installer didn't have a chance to flush the buffer, so the 
logging ends abruptly.

Original comment by BadPointer0 on 18 Mar 2015 at 6:18

[GoogleCodeExporter]

Sorry guys, I tried again this morning after rebooting and no worries now, 
everything works fine.
However, I have not invented yesterday and I had the same problem on 2 
computers, my Win7 x64 and a very new laptop with Win8.1 x64.
As it works this morning, I tried on a 3rd PC, also successfully.
It remained a mystery to me (same PCs, same config, no network concern) !!!, 
but well, it works now.
Sorry again, keep us your good work :) 

Original comment by Mateo.RO...@gmail.com on 18 Mar 2015 at 8:46

[GoogleCodeExporter]

Something must have been wrong with local network or ISP. Now that the issue 
resolved itself, we'll have to wait till it resurfaces(if it ever happens 
again).

It doesn't appear to be a racing condition issue because it was too consistent 
for that.

Original comment by BadPointer0 on 18 Mar 2015 at 8:51

[GoogleCodeExporter]

Just to let you know, as I had this concern, I downloaded, in the same time, as 
other tests, the full download app with driverpacks (8.55 GB) 
(http://snappy-driver-installer.sourceforge.net/SDI_Update.torrent) with 
µtorrent with nothing special on that side.
I do not know if it is good it reappear again (not for me) to understand why. I 
do not know more how to debug to find out what's wrong.
Thanks for your support :)

Original comment by Mateo.RO...@gmail.com on 18 Mar 2015 at 9:35

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I found SDI_R169D dump file on my win7 PC if it can help ?
https://dl.dropboxusercontent.com/u/16173277/SDI_R169D.exe.7924.7z
I do not have dump on the other Win8.1 PC, where I also tested libtorrent's 
client_test alone.

Original comment by Mateo.RO...@gmail.com on 18 Mar 2015 at 10:23

[GoogleCodeExporter]

The app was complied by GCC, not Microsoft Visual Studio. I don't think this 
dump file would be of any use.

It's not as easy to get backtrack on Windows as on Linux. It would be useful to 
know which steps can be taken to debug libtorrent.

Original comment by BadPointer0 on 18 Mar 2015 at 10:25

[GoogleCodeExporter]

for a second I thought that log was a stack trace, but it isn't. I still 
haven't seen anything to suggest the bug is even in libtorrent.

PadPointer0, I would expect you to be able to debug your program, presumably 
you built all the source. Probably this includes encoding version numbers in 
dump files and storing source and .pdb file or equivalent, then load dump files 
up in a debugger. I get the impression google breakpad is good at doing this.

Alternatively you could build with some amount of debug information enabled and 
produce stack traces from a crash handler/signal handler and log it when 
crashing.

Now, that doesn't mean it wasn't caused by a bug in libtorrent. For instance, 
it's very possible that ones location in the DHT affects what kinds of packets 
you're exposed to. Or that a specific peer in a swarm behaves strangely. 
Neither of those cases would be easy for someone else to reproduce. If any of 
you figure out where the crash happens, I'd be happy to take a look at at.

Original comment by arvid.no...@gmail.com on 20 Mar 2015 at 1:12

• Changed state: Invalid