Our nginx server is dumping core but I can’t debug the core file.
Ideas?
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type “show
copying”
and “show warranty” for details.
This GDB was configured as “sparc-sun-solaris2.10”…
“/myhome/nginx-0.7.68/html/core”: not in executable format: File format
not recognized
–
Robert La Ferla
VP Engineering
OMS SafeHarbor
This message (and any attachments) contains confidential information and
is protected by law. If you are not the intended recipient, you should
delete this message and are hereby notified that any disclosure,
copying, distribution, or the taking of any action based on this
message, is strictly prohibited.
Hello!
On Tue, Jan 4, 2011 at 20:37, Robert La Ferla [email protected]
wrote:
“/myhome/nginx-0.7.68/html/core”: not in executable format: File format not
recognized
Core file is not executable. You should pass path to nginx binary to gdb
first.
–
Boris D…
On Wed, Jan 5, 2011 at 00:35, Robert La Ferla [email protected]
wrote:
Thanks Boris.
Here is the stacktrace for the nginx crash bug: It’s in the 3rd party
secure download module.
Program terminated with signal 11, Segmentation fault.
[New process 73091 ]
#0 ngx_http_set_exten (r=0xc7f60) at src/http/ngx_http_core_module.c:1671
1671 if (r->uri.data[i] == ‘.’ && r->uri.data[i - 1] != ‘/’) {
What is the output of
p r
p r->uri
p i
–
Boris D…
Thanks Boris.
Here is the stacktrace for the nginx crash bug: It’s in the 3rd party
secure download module.
Program terminated with signal 11, Segmentation fault.
[New process 73091 ]
#0 ngx_http_set_exten (r=0xc7f60) at
src/http/ngx_http_core_module.c:1671
1671 if (r->uri.data[i] == ‘.’ && r->uri.data[i - 1] != ‘/’)
{
(gdb) bt
#0 ngx_http_set_exten (r=0xc7f60) at
src/http/ngx_http_core_module.c:1671
#1 0x0003f4fc in ngx_http_internal_redirect (r=0xc7f60, uri=0xc2e88,
args=0xc80f8) at src/http/ngx_http_core_module.c:2178
#2 0x00076248 in ngx_http_secure_download_handler (r=0xc7f60) at
/export/home/mb_stage/nginx-package/ngx_http_secure_download/ngx_http_secure_download_module.c:206
#3 0x0003db30 in ngx_http_core_access_phase (r=0xc7f60, ph=0xcca88) at
src/http/ngx_http_core_module.c:1009
#4 0x0003d744 in ngx_http_core_run_phases (r=0xc7f60) at
src/http/ngx_http_core_module.c:813
#5 0x0003d6dc in ngx_http_handler (r=0xc7f60) at
src/http/ngx_http_core_module.c:796
#6 0x00045458 in ngx_http_process_request (r=0xc7f60) at
src/http/ngx_http_request.c:1637
#7 0x0004465c in ngx_http_process_request_headers (rev=0xbac70) at
src/http/ngx_http_request.c:1080
#8 0x000441e0 in ngx_http_process_request_line (rev=0xf0c44) at
src/http/ngx_http_request.c:885
#9 0x00043b1c in ngx_http_init_request (rev=0xf0c44) at
src/http/ngx_http_request.c:510
#10 0x0002ea38 in ngx_event_process_posted (cycle=0xb6848,
posted=0xa4890) at src/event/ngx_event_posted.c:39
#11 0x0002d6c4 in ngx_process_events_and_timers (cycle=0xb6848) at
src/event/ngx_event.c:272
#12 0x0003506c in ngx_worker_process_cycle (cycle=0xb6848, data=0x0) at
src/os/unix/ngx_process_cycle.c:791
#13 0x00032c98 in ngx_spawn_process (cycle=0xb6848, proc=0x34f80
<ngx_worker_process_cycle>, data=0x0, name=0x7ab80 “worker process”,
respawn=0) at src/os/unix/ngx_process.c:194
#14 0x00034cdc in ngx_reap_children (cycle=0xb6848) at
src/os/unix/ngx_process_cycle.c:612
#15 0x000341ec in ngx_master_process_cycle (cycle=0xb6848) at
src/os/unix/ngx_process_cycle.c:180
#16 0x000194ec in main (argc=749672, argv=0xffbffc2c) at
src/core/nginx.c:396
–
Robert La Ferla
VP Engineering
OMS SafeHarbor
This message (and any attachments) contains confidential information and
is protected by law. If you are not the intended recipient, you should
delete this message and are hereby notified that any disclosure,
copying, distribution, or the taking of any action based on this
message, is strictly prohibited.
On 1/4/2011 5:47 PM, Boris D. wrote:
What is the output of
p r
p r->uri
p i
Program terminated with signal 11, Segmentation fault.
[New process 73091 ]
#0 ngx_http_set_exten (r=0xc7f60) at
src/http/ngx_http_core_module.c:1671
1671 if (r->uri.data[i] == ‘.’ && r->uri.data[i - 1] != ‘/’)
{
(gdb) p r
$1 = (ngx_http_request_t *) 0xc7f60
(gdb) p r->uri
$2 = {len = 3, data = 0xffffffff <Address 0xffffffff out of bounds>}
(gdb) p i
$3 = 2
–
Robert La Ferla
VP Engineering
OMS SafeHarbor
This message (and any attachments) contains confidential information and
is protected by law. If you are not the intended recipient, you should
delete this message and are hereby notified that any disclosure,
copying, distribution, or the taking of any action based on this
message, is strictly prohibited.
On Wed, Jan 5, 2011 at 02:06, Robert La Ferla [email protected]
wrote:
(gdb) p r
Sorry,
p *r
$2 = {len = 3, data = 0xffffffff <Address 0xffffffff out of bounds>}
Looks like ngx_http_secure_download_module performs internal redirect
to incorrect URL and you should consult with it’s author.
–
Boris D…
I solved this issue. nginx 0.7.x does not complain about the missing
variable secure_download_fail_location. Therefore, when an error occurs
in that module, the variable/URL is not found and it segfaults. I
believe later versions of nginx complain about the missing variable.
–
Robert La Ferla
VP Engineering
OMS SafeHarbor
This message (and any attachments) contains confidential information and
is protected by law. If you are not the intended recipient, you should
delete this message and are hereby notified that any disclosure,
copying, distribution, or the taking of any action based on this
message, is strictly prohibited.