Ticket #1232 (closed defect: fixed)

Opened 1 year ago

Last modified 1 year ago

Repeatable --- SIGSEGV (Segmentation fault) @ 0 (0) ---

Reported by: Olaf van der Spek Assigned to: jan
Priority: highest Milestone: 1.5.0
Component: core Version: 1.4.15
Severity: critical Keywords:
Cc: Blocking:
Need Feedback:

Description

If I repeat this request, Lighttpd crashes. 

GET / HTTP/1.1
Connection: keep-alive
Host: h
Location: h
Location: h
 i

Attachments

Change History

06/11/2007 03:14:15 PM changed by maze@strahlungsfrei.de

Doesn't happen on my r1857.

(follow-up: ↓ 3 ) 06/11/2007 10:38:42 PM changed by Olaf van der Spek

How do I map revision to version and the other way around?

(in reply to: ↑ 2 ; follow-up: ↓ 6 ) 06/12/2007 10:19:09 AM changed by anonymous

Replying to Olaf van der Spek:

How do I map revision to version and the other way around?

You can take a look at the /tags folder, you see the revisions the when the versions were tagged.

Version 1.4.15 was tagged in revision r1862

06/12/2007 10:25:30 AM changed by Olaf van der Spek

So Maze is running an untagged version. Maze, is your server public and can I try the request on it?

06/12/2007 12:30:09 PM changed by maze@strahlungsfrei.de

Olaf, please send a mail to maze@strahlungsfrei.de so I can send the hostname to you. Not everyone deserves to know the address..

(in reply to: ↑ 3 ) 06/12/2007 04:15:46 PM changed by Olaf van der Spek

Replying to anonymous:

Replying to Olaf van der Spek:

How do I map revision to version and the other way around?

You can take a look at the /tags folder, you see the revisions the when the versions were tagged. Version 1.4.15 was tagged in revision r1862

That doesn't tell you from which branch it is (1.4 or 1.5 for example).

06/12/2007 08:16:11 PM changed by robbat2

Just helping Olaf debug this. CFLAGS="-Os -mtune=970 -mcpu=970 -mabi=altivec -maltivec -pipe -Wstrict-aliasing -ggdb" 

(gdb) print b
$20 = (buffer *) 0x10206900
(gdb) print *b 
Cannot access memory at address 0x10206900

(gdb) frame
#0  buffer_prepare_copy (b=0x10206900, size=10) at buffer.c:76
76		if ((0 == b->size) ||
(gdb) up
#1  0x100134dc in buffer_copy_string_len (b=0x10206900, s=0x10081fb0 "text/html", s_len=9) at buffer.c:147
147		buffer_prepare_copy(b, s_len + 1);
(gdb) up
#2  0x1001d2e4 in response_header_insert (srv=<value optimized out>, con=0x100504d8, key=0xfaa6248 "Content-Type", keylen=12, value=0x10081fb0 "text/html", vallen=9) at http-header-glue.c:84
84		buffer_copy_string_len(ds->value, value, vallen);
(gdb) up
#3  0x0faa5518 in mod_staticfile_subrequest (srv=0x10037008, con=0x100504d8, p_d=0x100484d8) at mod_staticfile.c:442
442				response_header_overwrite(srv, con, CONST_STR_LEN("Content-Type"), CONST_BUF_LEN(sce->content_type));
(gdb) up
#4  0x100179b4 in plugins_call_handle_subrequest_start (srv=0xffffffff, con=0xa) at plugin.c:268
268	PLUGIN_TO_SLOT(PLUGIN_FUNC_HANDLE_SUBREQUEST_START, handle_subrequest_start)
(gdb) up
#5  0x10008ca4 in http_response_prepare (srv=0x10037008, con=0x100504d8) at response.c:618
618			switch(r = plugins_call_handle_subrequest_start(srv, con)) {
(gdb) up
#6  0x1000aa5c in connection_state_machine (srv=0x10037008, con=0x100504d8) at connections.c:1400
1400				switch (r = http_response_prepare(srv, con)) {
(gdb) up
#7  0x10007df8 in main (argc=268662144, argv=<value optimized out>) at server.c:1334
1334				connection_state_machine(srv, con);
(gdb) up
Initial frame selected; you cannot go up.




(gdb) bt full
#0  buffer_prepare_copy (b=0x10206900, size=10) at buffer.c:76
	__PRETTY_FUNCTION__ = "buffer_prepare_copy"
#1  0x100134dc in buffer_copy_string_len (b=0x10206900, s=0x10081fb0 "text/html", s_len=9) at buffer.c:147
No locals.
#2  0x1001d2e4 in response_header_insert (srv=<value optimized out>, con=0x100504d8, key=0xfaa6248 "Content-Type", keylen=12, value=0x10081fb0 "text/html", vallen=9) at http-header-glue.c:84
	ds = (data_string *) 0x10081bb0
#3  0x0faa5518 in mod_staticfile_subrequest (srv=0x10037008, con=0x100504d8, p_d=0x100484d8) at mod_staticfile.c:442
	k = <value optimized out>
	sce = (stat_cache_entry *) 0x10082228
	mtime = <value optimized out>
#4  0x100179b4 in plugins_call_handle_subrequest_start (srv=0xffffffff, con=0xa) at plugin.c:268
	r = <value optimized out>
	slot = (plugin **) 0x10047ce0
	j = 7
#5  0x10008ca4 in http_response_prepare (srv=0x10037008, con=0x100504d8) at response.c:618
	st = {st_dev = 8589934595, st_ino = 1155199224817136144, st_mode = 4289630848, st_nlink = 268514828, st_uid = 268965704, st_gid = 268660744, st_rdev = 18423824204072747009, 
  __pad2 = 4104, st_size = -22919457051439752, st_blksize = 0, st_blocks = 1156261752212553728, st_atim = {tv_sec = 2, tv_nsec = 268965718}, st_mtim = {tv_sec = 3, tv_nsec = 268662144}, 
  st_ctim = {tv_sec = 0, tv_nsec = 0}, __unused4 = 269213168, __unused5 = 0}
	slash = <value optimized out>
	pathinfo = 0x100506f8 "\020\b\025ΒΈ"
	sce = (stat_cache_entry *) 0x10081f10
	r = HANDLER_GO_ON
#6  0x1000aa5c in connection_state_machine (srv=0x10037008, con=0x100504d8) at connections.c:1400
	ostate = 5
	b = 1
	r = <value optimized out>
	srv_sock = (server_socket *) 0x10047c00
#7  0x10007df8 in main (argc=268662144, argv=<value optimized out>) at server.c:1334
	con = (connection *) 0x100504d8
	r = <value optimized out>
	srv = (server *) 0xffffffff
	print_config = 268475292
	test_config = <value optimized out>
	i_am_root = <value optimized out>
	o = <value optimized out>
	num_childs = <value optimized out>
	pid_fd = 1
	fd = <value optimized out>
	i = <value optimized out>
	act = {__sigaction_handler = {sa_handler = 0x100061c0 <sigaction_handler>, sa_sigaction = 0x100061c0 <sigaction_handler>}, sa_mask = {__val = {0 <repeats 32 times>}}, sa_flags = 4, 
  sa_restorer = 0}
	rlim = {rlim_cur = 1014, rlim_max = 1024}

06/12/2007 08:20:23 PM changed by robbat2

The above trace is from lighttpd-1.4.15, on ppc64 with a 32 bit userland. Portage 2.1.2.5 (default-linux/ppc/ppc64/2006.1/32bit-userland/970/pmac, gcc-4.1.2, glibc-2.5-r1, 2.6.18-g64134594-dirty ppc64)

The initialization of ds->value in data_string_init appears to be at fault, not sure why yet, still tracing more.

06/12/2007 08:59:26 PM changed by robbat2@gentoo.org

Ok, while single-stepping, I see that the data_response_init branch is seldom taken, and the bad ds structure is coming from array_get_unused_element.

valgrind's memcheck fails to find any bad memory usage, possibly time to use electricfence.

06/15/2007 02:17:24 PM changed by jan

  • status changed from new to closed.
  • resolution set to fixed.

fixed in [1869]

Add/Change #1232 (Repeatable --- SIGSEGV (Segmentation fault) @ 0 (0) ---)




Change Properties
Action