Passed: apache/httpd#608 (2.4.x - 59535a6)

[Travis CI]

Build Update for apache/httpd
-

Build: #608
Status: Passed

Duration: 20 mins and 9 secs
Commit: 59535a6 (2.4.x)
Author: Joe Orton
Message: Merge r1876623 from trunk:

Allow failures for the gcc9 build since the repo seems to have broken deps.

[under CTR for Travis stuff]


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1876627 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/httpd/compare/0c53ee9dbe08...59535a6c8b66

View the full build log and details: 
https://travis-ci.org/github/apache/httpd/builds/675878043?utm_medium=notification&utm_source=email

--

You can unsubscribe from build emails from the apache/httpd repository going to 
https://travis-ci.org/account/preferences/unsubscribe?repository=69847&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Errored: apache/httpd#603 (2.4.x - 0c53ee9)

[Travis CI]

Build Update for apache/httpd
-

Build: #603
Status: Errored

Duration: 26 mins and 40 secs
Commit: 0c53ee9 (2.4.x)
Author: Stefan Eissing
Message: backport proposal for PR64330

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1876617 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/httpd/compare/8f50ac3cd2f2...0c53ee9dbe08

View the full build log and details: 
https://travis-ci.org/github/apache/httpd/builds/675851049?utm_medium=notification&utm_source=email

--

You can unsubscribe from build emails from the apache/httpd repository going to 
https://travis-ci.org/account/preferences/unsubscribe?repository=69847&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Re: mod_http2 crashes libhttpd.dll in 2.4.43

[Stefan Eissing]

🤢🙈

Fixed in 
and apache trunk as r1876616 and proposed for backport.

~Stefan

> Am 16.04.2020 um 13:51 schrieb Rainer Jung :
> 
> 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  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]
> 0x7ffbe57515d9 in libhttpd!ap_get_server_built () from 
> X:\Apps\Apache24\bin\libhttpd.dll
> (gdb) bt
> #0 0x7ffbe57515d9 in libhttpd!ap_get_server_built () from 
> X:\Apps\Apache24\bin\libhttpd.dll
> #1 0x7ffbe44d14aa in ?? () from X:\Apps\Apache24\modules\mod_cgi.so
> #2 0x7ffbe575ee85 in libhttpd!ap_run_handler () from 
> X:\Apps\Apache24\bin\libhttpd.dll
> #3 0x7ffbe575da7f in libhttpd!ap_invoke_handler () from 
> X:\Apps\Apache24\bin\libhttpd.dll
> #4 0x7ffbe575a62a in libhttpd!ap_internal_redirect_handler () from 
> X:\Apps\Apache24\bin\libhttpd.dll
> #5 0x7ffbe575a6af in libhttpd!ap_process_request () from 
> X:\Apps\Apache24\bin\libhttpd.dll
> #6 0x7ffbe22888ef in ?? () from X:\Apps\Apache24\modules\mod_http2.so
> #7 0x7ffbe5761545 in libhttpd!ap_run_process_connection () from 
> X:\Apps\Apache24\bin\libhttpd.dll
> #8 0x7ffbe22885ba in ?? () from X:\Apps\Apache24\modules\mod_http2.so
> #9 0x7ffbe228c36e in ?? () from X:\Apps\Apache24\modules\mod_http2.so
> #10 0x7ffbe9e30e72 in ucrtbase!_beginthreadex () from 
> C:\Windows\System32\ucrtbase.dll
> #11 0x7ffbea107bd4 in KERNEL32!BaseThreadInitThunk () from 
> C:\Windows\System32\kernel32.dll
> #12 0x7ffbebecced1 in ntdll!RtlUserThreadStart () from 
> C:\Windows\SYSTEM32\ntdll.dll
> #13 0x 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.

Re: mod_http2 crashes libhttpd.dll in 2.4.43

[Rainer Jung]

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  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]
0x7ffbe57515d9 in libhttpd!ap_get_server_built () from 
X:\Apps\Apache24\bin\libhttpd.dll

(gdb) bt
#0 0x7ffbe57515d9 in libhttpd!ap_get_server_built () from 
X:\Apps\Apache24\bin\libhttpd.dll

#1 0x7ffbe44d14aa in ?? () from X:\Apps\Apache24\modules\mod_cgi.so
#2 0x7ffbe575ee85 in libhttpd!ap_run_handler () from 
X:\Apps\Apache24\bin\libhttpd.dll
#3 0x7ffbe575da7f in libhttpd!ap_invoke_handler () from 
X:\Apps\Apache24\bin\libhttpd.dll
#4 0x7ffbe575a62a in libhttpd!ap_internal_redirect_handler () 
from X:\Apps\Apache24\bin\libhttpd.dll
#5 0x7ffbe575a6af in libhttpd!ap_process_request () from 
X:\Apps\Apache24\bin\libhttpd.dll
#6 0x7ffbe22888ef in ?? () from 
X:\Apps\Apache24\modules\mod_http2.so
#7 0x7ffbe5761545 in libhttpd!ap_run_process_connection () from 
X:\Apps\Apache24\bin\libhttpd.dll
#8 0x7ffbe22885ba in ?? () from 
X:\Apps\Apache24\modules\mod_http2.so
#9 0x7ffbe228c36e in ?? () from 
X:\Apps\Apache24\modules\mod_http2.so
#10 0x7ffbe9e30e72 in ucrtbase!_beginthreadex () from 
C:\Windows\System32\ucrtbase.dll
#11 0x7ffbea107bd4 in KERNEL32!BaseThreadInitThunk () from 
C:\Windows\System32\kernel32.dll
#12 0x7ffbebecced1 in ntdll!RtlUserThreadStart () from 
C:\Windows\SYSTEM32\ntdll.dll

#13 0x 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.

Re: mod_http2 crashes libhttpd.dll in 2.4.43

[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  
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]
0x7ffbe57515d9 in libhttpd!ap_get_server_built () from 
X:\Apps\Apache24\bin\libhttpd.dll

(gdb) bt
#0  0x7ffbe57515d9 in libhttpd!ap_get_server_built () from 
X:\Apps\Apache24\bin\libhttpd.dll
#1  0x7ffbe44d14aa in ?? () from 
X:\Apps\Apache24\modules\mod_cgi.so
#2  0x7ffbe575ee85 in libhttpd!ap_run_handler () from 
X:\Apps\Apache24\bin\libhttpd.dll
#3  0x7ffbe575da7f in libhttpd!ap_invoke_handler () from 
X:\Apps\Apache24\bin\libhttpd.dll
#4  0x7ffbe575a62a in libhttpd!ap_internal_redirect_handler () 
from X:\Apps\Apache24\bin\libhttpd.dll
#5  0x7ffbe575a6af in libhttpd!ap_process_request () from 
X:\Apps\Apache24\bin\libhttpd.dll
#6  0x7ffbe22888ef in ?? () from 
X:\Apps\Apache24\modules\mod_http2.so
#7  0x7ffbe5761545 in libhttpd!ap_run_process_connection () from 
X:\Apps\Apache24\bin\libhttpd.dll
#8  0x7ffbe22885ba in ?? () from 
X:\Apps\Apache24\modules\mod_http2.so
#9  0x7ffbe228c36e in ?? () from 
X:\Apps\Apache24\modules\mod_http2.so
#10 0x7ffbe9e30e72 in ucrtbase!_beginthreadex () from 
C:\Windows\System32\ucrtbase.dll
#11 0x7ffbea107bd4 in KERNEL32!BaseThreadInitThunk () from 
C:\Windows\System32\kernel32.dll
#12 0x7ffbebecced1 in ntdll!RtlUserThreadStart () from 
C:\Windows\SYSTEM32\ntdll.dll

#13 0x 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.