🤢🙈
Fixed in <https://github.com/icing/mod_h2/releases/tag/v1.15.8>
and apache trunk as r1876616 and proposed for backport.
~Stefan
> Am 16.04.2020 um 13:51 schrieb Rainer Jung <rainer.j...@kippdata.de>:
>
> If I get this right, there is an element in elts, that has a valid string key
> ("H2_STREAM_ID") bis a NULL value (2nd screenshot) and the condition check in
> line 527 of the first screen shot checks key against NULL and empty, but
> value only against empty but not against NULL. So the empty check derefences
> NULL.
>
> Nut sure what the correct fix is:
>
> - make sure the H2_STREAM_IS value is never NULL (but maybe empty)
> - add NULL check for the value to the list of checks in 527
> - something else
>
> At least the debug info provided by Steffen seems to be a good fit to the
> stream id handling changes in the revision in question (but i have not
> checked, whether the NULL is new). I think a fix is close :)
>
> Thanks and regards,
>
> Rainer
>
> Am 16.04.2020 um 10:12 schrieb Steffen:
>> 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.
