Crash during list update

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Fresh install of r65
2. During first run, crashed during list-update

Peerblock.log and .dmp files submitted via email, dump needs triage.

Original issue reported on code.google.com by peerbloc...@gmail.com on 26 Jul 2009 at 5:21

[GoogleCodeExporter]

Looks like a crash in the libcurl code.

STACK_TEXT:  
0396fecc 00467630 014e0b78 0000001f 0142a468 
peerblock!Curl_llist_insert_next+0x35
0396fee4 0046699c 014d1b28 014bde90 0142a468 peerblock!Curl_hash_add+0xa0
0396ff08 0046b65c 0150c838 014bde18 00000000 peerblock!Curl_cache_addr+0x5c
0396ff44 004da01f 01518600 d5dc5013 00000000 
peerblock!Curl_splayremovebyaddr+0x2ec
0396ff7c 004da0c7 00000000 0396ff94 754b10dc peerblock!_callthreadstartex+0x1b
[f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c @ 348]
0396ff88 754b10dc 01518b78 0396ffd4 77041e9e peerblock!_threadstartex+0x82
[f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c @ 326]
0396ff94 77041e9e 01518b78 7c44f309 00000000 kernel32!BaseThreadInitThunk+0xe
0396ffd4 77041e71 004da045 01518b78 00000000 ntdll!__RtlUserThreadStart+0x70
0396ffec 00000000 004da045 01518b78 00000000 ntdll!_RtlUserThreadStart+0x1b

Original comment by peerbloc...@gmail.com on 26 Jul 2009 at 4:24

[GoogleCodeExporter]

I believe this is the problem Michael O. reported to me via email:

int
Curl_llist_insert_next(struct curl_llist *list, struct curl_llist_element *e,
                       const void *p)
{
  struct curl_llist_element *ne = malloc(sizeof(struct curl_llist_element));
  if(!ne)
    return 0;

  ne->ptr = (void *) p;
  if(list->size == 0) {
    list->head = ne;
    list->head->prev = NULL;
    list->head->next = NULL;
    list->tail = ne;
  }
  else {
    ne->next = e->next;          // sometimes the e pointer was null here

Original comment by peerbloc...@gmail.com on 27 Jul 2009 at 2:32

[GoogleCodeExporter]

Not sure if I trust my stack-trace; WinDbg might have gotten some confused 
symbols
somewhere (or we could be experiencing stack corruption, or something).  The 
above
stack-trace I posted shows Curl_splayremovebyaddr() being called apparently as 
the
first routine of a new thread, which just doesn't make sense at first glance.  
And
more importantly, I cannot see anyplace in the Curl_splayremovebyaddr() code 
where
it's calling Curl_cache_addr, the next item down in the call stack.

From a quick Google search on crashes in Curl_llist_insert_next, all references 
I see
are to stack traces showing the problem originating in a 
Curl_addrinfo4_callback()
from the gethostbyname_thread.  Apparently there's a problem in the Windows
multi-threaded name-resolver, has popped up over the years but has never been 
chased
down.  Peoples' suggested workarounds are to either switch to a synchonous
name-resolver, or else "C-Ares" which apparently works best of all.

Might be worth looking into setting up libcurl to compile with this "C-Ares"
name-resolver, and see if it gets rid of this problem for us.

Original comment by peerbloc...@gmail.com on 27 Jul 2009 at 3:33

[GoogleCodeExporter]

Some links to reports of this exact same kind of crash in 
Curl_llist_insert_next:

- Possible bug in libcurl, from 2007 but closed due to no repro-case code:
http://sourceforge.net/tracker/?func=detail&atid=100976&aid=1833734&group_id=976

- Might need to "hack setup.h" to turn off asynchronous resolving:
http://curl.haxx.se/mail/lib-2009-03/0112.html

Original comment by peerbloc...@gmail.com on 27 Jul 2009 at 3:37

[GoogleCodeExporter]

Original comment by peerbloc...@gmail.com on 27 Jul 2009 at 7:03

• Changed state: Started

[GoogleCodeExporter]

I have patched around this problem in r66.  Haven't actually fixed the root 
cause of
the bug in the libcurl code, but at least if we hit it now we should be able to
recover and not crash.

Original comment by peerbloc...@gmail.com on 28 Jul 2009 at 3:17

• Changed state: Fixed

[GoogleCodeExporter]

I've added a comment to r67 incase email notification don't work.

Original comment by nightstalkerz on 28 Jul 2009 at 4:44

[GoogleCodeExporter]

Reopening this bug, as the previous workaround patch doesn't fix all cases.  As 
per
the dump from zerocoolxp's post in this thread in our forum
(http://forums.peerblock.com/read.php?3,482,501#msg-501), the linked-list 
libcurl is
choking on can still be fubar.

Doing some more research into the root libcurl bug, this appears to be "Known 
Issue #64":

  64. The threaded resolver used in libcurl on Windows has some kind of race
    problem when multiple simultanoes resolves are done, like with the multi
    interface transferring many files in parallell:
    http://curl.haxx.se/mail/lib-2009-04/0028.html

  from (http://curl.haxx.se/docs/knownbugs.html)

We do have a couple of workarounds available based on the email thread 
linked-to.  We
can rebuild libcurl to make use of the "c-ares" resolver, or we can setup a curl
"share" for our "easy interface" networking stuff.  This latter option doesn't 
appear
to be quite as straightforward as you might think, but is probably the least 
intrusive.

Original comment by peerbloc...@gmail.com on 8 Sep 2009 at 11:40

• Changed state: Started
• Added labels: Milestone-Release1.0
• Removed labels: Milestone-Release0.9.1

[GoogleCodeExporter]

Retargetting for PeerBlock 1.1

Original comment by peerbloc...@gmail.com on 29 Sep 2009 at 3:56

• Added labels: Milestone-Release1.1
• Removed labels: Milestone-Release1.0

[GoogleCodeExporter]

Original comment by peerbloc...@gmail.com on 30 Sep 2009 at 4:20

• Added labels: Milestone-1.1
• Removed labels: Milestone-Release1.1

[GoogleCodeExporter]

Issue 149 has been merged into this issue.

Original comment by peerbloc...@gmail.com on 6 Oct 2009 at 1:38

[GoogleCodeExporter]

Hi there,
I' like to report this problem happens more often when you launch PeerBlock 
while the
network connection is not "ready" yet.

Here are the steps I do:

1 - Turn on my PC with network cable disconnected.
2 - Plug in the network cable and, AT THE SAME TIME,
3 - Launch Peerblock before an IP address has been negotiated between the PC 
and the
DHCP server.

Unless the PC has an address assigned, PB will crash; WARNING: tray icon is 
still
displayed (so I could think everything is running fine) BUT it will disappear 
as soon
as the mouse cursor hovers the tray bar.

I have to repeat the procedure 2-3 times before PB begins working correctly...
pleease fix it! :-)

Hope my comment is useful to someone.
MAx - Italy

PS. My configuration:

- ADSL router with internal switch (Linksys AG241)
- 1 desktop PC
- 1 Laptop PC (which currently runs PeerBlock)

Original comment by mula...@gmail.com on 26 Jan 2010 at 10:15

[GoogleCodeExporter]

i've had no problems what so ever with it since installing the beta version, 
and it
runs perfect on my laptop.it boots with windows  an it dosnt make any difference
whether its connected to the net or not.

Original comment by ukgh...@googlemail.com on 26 Jan 2010 at 11:18

[GoogleCodeExporter]

An exception occured!

Build Number: 40911210223
File: .\updatelists.cpp
Line: 647
Type: class path_error
Message: Access is denied.

Original comment by bones9...@gmail.com on 7 Feb 2010 at 4:39

[GoogleCodeExporter]

This issue was closed by revision r278.

Original comment by peerbloc...@gmail.com on 12 Feb 2010 at 5:26

• Changed state: Fixed

[GoogleCodeExporter]

Fantastic!

Original comment by TheG...@gmail.com on 13 Feb 2010 at 1:54