More info.
See CallStack
www.apachelounge.com/download/VS16/modules/CallStack.png
and
www.apachelounge.com/download/VS16/modules/autos.png
Below we had:
libhttpd!ap_get_server_built+0x5d9
mod_cgi+0x14aa
libhttpd!ap_run_handler+0x35
libhttpd!ap_invoke_handler+0x10f
libhttpd!ap_internal_redirect_handler+0x29a
libhttpd!ap_process_request+0xf
mod_http2+0x188ef
libhttpd!ap_run_process_connection+0x35
mod_http2+0x185ba
mod_http2+0x1c36e
ucrtbase!beginthreadex+0x142
kernel32!BaseThreadInitThunk+0x14
ntdll!RtlUserThreadStart+0x21
Steffen
On Tuesday 14/04/2020 at 14:13, Eric Covener wrote:
On Tue, Apr 14, 2020 at 8:09 AM Ruediger Pluem <rpl...@apache.org>
wrote:
On 4/14/20 12:22 PM, Steffen wrote:
This is the post above of backtrace
Thanks.
By accident I've seen that Perl comes with GDB. This might help as
well.
I called httpd.exe from GDB with "-X -e debug" and then called a Perl
URL in the browser.
Excerpt below:
Somehow the below wasn't visible in the original mail.
Thread 100 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 4936.0x23e0]
0x00007ffbe57515d9 in libhttpd!ap_get_server_built () from
X:\Apps\Apache24\bin\libhttpd.dll
(gdb) bt
#0 0x00007ffbe57515d9 in libhttpd!ap_get_server_built () from
X:\Apps\Apache24\bin\libhttpd.dll
#1 0x00007ffbe44d14aa in ?? () from
X:\Apps\Apache24\modules\mod_cgi.so
#2 0x00007ffbe575ee85 in libhttpd!ap_run_handler () from
X:\Apps\Apache24\bin\libhttpd.dll
#3 0x00007ffbe575da7f in libhttpd!ap_invoke_handler () from
X:\Apps\Apache24\bin\libhttpd.dll
#4 0x00007ffbe575a62a in libhttpd!ap_internal_redirect_handler ()
from X:\Apps\Apache24\bin\libhttpd.dll
#5 0x00007ffbe575a6af in libhttpd!ap_process_request () from
X:\Apps\Apache24\bin\libhttpd.dll
#6 0x00007ffbe22888ef in ?? () from
X:\Apps\Apache24\modules\mod_http2.so
#7 0x00007ffbe5761545 in libhttpd!ap_run_process_connection () from
X:\Apps\Apache24\bin\libhttpd.dll
#8 0x00007ffbe22885ba in ?? () from
X:\Apps\Apache24\modules\mod_http2.so
#9 0x00007ffbe228c36e in ?? () from
X:\Apps\Apache24\modules\mod_http2.so
#10 0x00007ffbe9e30e72 in ucrtbase!_beginthreadex () from
C:\Windows\System32\ucrtbase.dll
#11 0x00007ffbea107bd4 in KERNEL32!BaseThreadInitThunk () from
C:\Windows\System32\kernel32.dll
#12 0x00007ffbebecced1 in ntdll!RtlUserThreadStart () from
C:\Windows\SYSTEM32\ntdll.dll
#13 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)
Unfortunately this stacktrace does not help. One reason might be that
the debugging symbols are missing.
It is very strange that it segfaults in ap_get_server_built, a simple
function just returning a pointer
to a static string constant. Furthermore ap_get_server_built is not
called by mod_cgi.
Can the crash be repeated against a binary with debugging symbols that
are then used to generate the stacktrace?
As I am not a Windows guy, I unfortunately cannot provide any
instructions how to do this.
My experience on windows is that if the PDB's are not 110% right you
will get all kinds of misleading stuff above the first ?? in the
displayed backtrace.
