Bug #2391

Crash SIGBUS

Added by 1ApRiL over 2 years ago. Updated over 2 years ago.

Status:FixedStart date:2012-02-19
Priority:NormalDue date:
Assignee:-% Done:

100%

Category:mod_compress
Target version:-
Missing in 1.5.x:No

Description

Version: lighttpd/1.4.30

After lighttpd went down several times. I attached gdb to it.

This is what I got:
(gdb) continue
Continuing.

Program received signal SIGBUS, Bus error.
0x000000000041f4c2 in generate_crc32c (buffer=0x7f044e7b8000 "\211PNG\r\n\032\n", length=22305) at crc32.c:78
78 CRC32Cbuffer[i]);
(gdb) bt
#0 0x000000000041f4c2 in generate_crc32c (buffer=0x7f044e7b8000 "\211PNG\r\n\032\n", length=22305) at crc32.c:78
#1 0x00007f044b4e3b40 in deflate_file_to_buffer_gzip (srv=<value optimized out>, con=<value optimized out>, p=0x1932ca0, start=0x7f044e7b8000 "\211PNG\r\n\032\n", st_size=22305,
mtime=<value optimized out>) at mod_compress.c:291
#2 0x00007f044b4e4c6a in deflate_file_to_file (srv=0x1910010, con=0x195ba60, p_d=0x1932ca0) at mod_compress.c:506
#3 mod_compress_physical (srv=0x1910010, con=0x195ba60, p_d=0x1932ca0) at mod_compress.c:816
#4 0x000000000041b548 in plugins_call_handle_subrequest_start (srv=0x1910010, con=0x195ba60) at plugin.c:272
#5 0x000000000040a158 in http_response_prepare (srv=0x1910010, con=0x195ba60) at response.c:724
#6 0x000000000040d689 in connection_state_machine (srv=0x1910010, con=0x195ba60) at connections.c:1456
#7 0x00000000004094a2 in main (argc=<value optimized out>, argv=<value optimized out>) at server.c:1495

The only thing which I access with this is static files from munin.

The backtrace looks like it has something todo with mod_compress. I will deactivate that mod in the hope it runs more stable.

Associated revisions

Revision 2827
Added by stbuehler over 2 years ago

Disable mmap by default (fixes #2391)

  • if a user truncates a file we are mmapping, reading the truncated
    area leads to SIGBUS
  • mod_cgi and mod_webdav still use mmap for reading the tmp files
    created for large request bodies.
    as no other user should have write access for those this isn't
    a (security) problem.

History

#1 Updated by darix over 2 years ago

  • Status changed from New to Need Feedback
  1. why do you compress png files?
  2. could it be you replace the png files regularly? and that it crashes when a file got replaced?

#2 Updated by 1ApRiL over 2 years ago

1. Good question. I tested now if it makes sense to compress png. Result: No, it only saves less than 0.2% of traffic.
2. Yes, munin replaces the png files every 5 minutes. Maybe lighttpd compressed the png while it was rewritten. That could be the reason.

So I know now that compressing PNG is stupid and you know that a possible reason for crash could be a file change while compressing.

#3 Updated by stbuehler over 2 years ago

while we really should fix the crash, you really need to update files atomically, i.e. create new tmp file in same directory, then move into place; otherwise the http client might see a (truncated) mix between old and new versions.

#4 Updated by stbuehler over 2 years ago

  • Status changed from Need Feedback to Fixed
  • % Done changed from 0 to 100

Applied in changeset r2827.

Also available in: Atom