Encountering SIGSEGV after on successful request (statically linked, libpacparser, ppc64le) #17
Comments
|
For reference: ret = direct_request(thread_data, request);
#ifdef ENABLE_PACPARSER
} else if (pacparser_initialized) {
/* If PAC is available, use it to serve request. */
ret = pac_forward_request(thread_data, request, pac_list);
} else {
/* Else use statically configured proxies. */
ret = forward_request(thread_data, request, NULL);
}
#else
}
else
ret = forward_request(thread_data, request);
#endif
if (debug)
printf("proxy_thread: request rc = %p\n", (void *)ret);
#ifdef ENABLE_PACPARSER
} while (ret != NULL && ret != (void *)-1 && ret != (void *)-2);
#else
} while (ret != NULL && ret != (void *)-1);
#endif
if (debug)
printf("proxy_thread: request rc = %p\n", (void *)&request);
free_rr_data(&request);
/*
* If client asked for proxy keep-alive, loop unless the last server response
* requested (Proxy-)Connection: close.
*/
#ifdef ENABLE_PACPARSER
} while (keep_alive && ret != (void *)-1 && ret != (void *)-2 && !serialize);
#else
} while (keep_alive && ret != (void *)-1 && !serialize);
#endif
/*
* Add ourselves to the "threads to join" list.
*/
if (!serialize) {
if (debug)
printf("threads_mtx = %p\n", &threads_mtx);
pthread_mutex_lock(&threads_mtx);
pthread_t thread_id = pthread_self();
threads_list = plist_add(threads_list, (unsigned long)thread_id, NULL);
pthread_mutex_unlock(&threads_mtx);
}
#ifdef ENABLE_PACPARSER
plist_free(pac_list);
#endif
free(thread_data);
close(cd);
return NULL;
}Another important note- this was cross-compiled, so I'll need to try with a native toolchain on a ppc64le host to see if that may be part of the cause |
|
It appears that this is associated with a linking mistake made by a human, specifically, me. I would like to:
|
|
Maybe I misunderstand something, but what happens when you compile with debug symbols and type |
|
@jschwartzenberg I think your guess that you may be misunderstanding is correct. If you're reading this issue as "bug in libpacparser" then it's a misunderstanding- sorry for that. If you look at the backtrace above, it's dying in Obviously It's theoretically possible that libpacparser to be at fault, but there's no indication of that. I included libpacparser in the title of the issue because libpacparser is statically linked into it- meaning only that it's not a typical build If you're just curious about the bug then I have some more details as I've traced it back a little bit. Also, I noticed that building with Anyway, if you want to see what gdb thinks the faulting line of code is, here it is with Somehow it's getting NULL for the address that holds the values used to reset the timeval structure, and faulting while resetting it on line 1873 ( Line 1873 in d546bfe So it looks relatively straightforward, a pointer to I let it continue, idle for a few Now I make the request to try to trigger the SIGSEGV... The fault is coming, but it will break first... So Continuing on, to let it crash... I'm not going to dig into how/why this is happening- but if I was going to start, it would be by setting a watchpoint on I should probably just close, I don't want to waste anyone else's time (or my own time!) any further :) BTW- I think letting it run with the sanitizer flags might cause the |
|
I'm going to close this before it distracts or confuses anyone else :) The issue goes away when the static library archive is produced properly anyway |
Using the "feature" I submitted (static linking) in #16 I'm encountering a failure that seems to be associated with joining a thread after a request is complete. I'm entering this just for awareness and as a reminder for me to look further into it, I doubt you want to be supporting/debugging ppc64le & statically linked CNTLM- if you even have access to a ppc64le Linux machine :)
The request finishes successfully (the client gets the results) but then cntlm goes down with a SIGSEGV:
In gdb, I'm seeing this, it appears to be a NULL pointer dereference, likely associated wioth the -1 return from
proxy_thread():I'll look into this more as I get a chance. If you prefer, you can close the issue here and I can open it on my fork
The text was updated successfully, but these errors were encountered: