* report a segment fault bug of systemtap
@ 2013-12-28 11:52 maliubiao
2013-12-28 12:22 ` maliubiao
2014-01-11 18:10 ` Frank Ch. Eigler
0 siblings, 2 replies; 4+ messages in thread
From: maliubiao @ 2013-12-28 11:52 UTC (permalink / raw)
To: systemtap
SCRIPT :
global c = 0;
probe process("/data/project/c/nginx-build/sbin/nginx").function("ngx_worker_process_cycle")
{
if (c < 1) {
printf("%s\n", user_string($cycle->hostname->data))
c += 1
}
}
probe process("/data/project/c/nginx-build/sbin/nginx").function("ngx_epoll_process_events*")
{
/* iter over array ngx_modules */
for (i=0; i < 512; i++) {
index = @var("ngx_modules@ngx_modules.c")[i]->index
if (index != i) {
break
}
ngx_modules = @var("ngx_modules@ngx_modules.c")[i]
ctx = @cast(ngx_modules, "ngx_module_s")->ctx
name = @cast(ctx, "ngx_core_module_t")->name->data
if (name) {
printf("index: %s\n", i, user_string(name));
}
}
}
STACK TRACE:
Pass 1: parsed user script and 100 library script(s) using
89752virt/29968res/2480shr/28316data kb, in 150usr/10sys/26180real ms.
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff777e946 in __strcmp_sse42 () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff777e946 in __strcmp_sse42 () from /lib64/libc.so.6
#1 0x00000000004d57ad in dwarf_atvar_query::atvar_query_cu (cudie=0x24028a0,
data=0x7fffffffba80) at tapsets.cxx:4192
#2 0x000000000054a862 in dwflpp::iterate_over_cus (this=<optimized out>,
callback=0x4d5760 <dwarf_atvar_query::atvar_query_cu(Dwarf_Die*, void*)>,
data=0x7fffffffba80, want_types=false) at dwflpp.cxx:466
#3 0x00000000004b48cd in query_module (mod=<optimized out>,
name=<optimized out>, addr=4194304, arg=0x7fffffffba80) at tapsets.cxx:2132
#4 0x00007ffff71edfa2 in dwfl_getmodules (dwfl=0x228cd60,
callback=0x4b4770 <query_module(Dwfl_Module*, void**, char const*,
Dwarf_Addr, void*)>, arg=0x7fffffffba80, offset=0)
at ../.././elfutils-0.157/libdwfl/dwfl_getmodules.c:82
#5 0x00000000004ca254 in dwarf_atvar_expanding_visitor::visit_atvar_op (
this=0x2284b40, e=0x23c4030) at tapsets.cxx:4296
#6 0x0000000000453fb3 in update_visitor::require<expression> (this=0x2284b40,
src=<optimized out>, clearok=false) at staptree.h:970
#7 0x00000000004c8e2b in replace<expression> (clearok=false,
src=@0x23c3d88: 0x23c4030, this=0x2284b40) at staptree.h:992
#8 var_expanding_visitor::rewrite_lvalue (this=this@entry=0x2284b40,
tok=0x21eeaf0, eop="=", lvalue=@0x23c3d78: 0x23c3da0,
rvalue=@0x23c3d88: 0x23c4030) at tapsets.cxx:2354
#9 0x00000000004c9369 in var_expanding_visitor::visit_assignment (
this=0x2284b40, e=0x23c3d60) at tapsets.cxx:2400
---Type <return> to continue, or q <return> to quit---
#10 0x000000000044e1df in assignment::visit (this=0x23c3d60, u=0x2284b40)
at staptree.cxx:1469
#11 0x0000000000453fb3 in update_visitor::require<expression> (this=0x2284b40,
src=<optimized out>, clearok=false) at staptree.h:970
#12 0x000000000044c587 in replace<expression> (clearok=false,
src=<optimized out>, this=0x2284b40) at staptree.h:992
#13 update_visitor::visit_expr_statement (this=0x2284b40, s=0x23c3d40)
at staptree.cxx:2599
#14 0x000000000044a5bf in require<statement> (clearok=false,
src=<optimized out>, this=0x2284b40) at staptree.h:970
#15 replace<statement> (clearok=false, src=@0x23c3d00: 0x23c3d40,
this=0x2284b40) at staptree.h:992
#16 update_visitor::visit_block (this=0x2284b40, s=0x23c3cd0)
at staptree.cxx:2571
#17 0x0000000000453af3 in update_visitor::require<statement> (this=0x2284b40,
src=<optimized out>, clearok=false) at staptree.h:970
#18 0x000000000044cd8d in replace<statement> (clearok=false,
src=@0x23c37b8: 0x23c3cd0, this=0x2284b40) at staptree.h:992
#19 update_visitor::visit_for_loop (this=0x2284b40, s=0x23c3790)
at staptree.cxx:2618
#20 0x000000000044a5bf in require<statement> (clearok=false,
src=<optimized out>, this=0x2284b40) at staptree.h:970
#21 replace<statement> (clearok=false, src=@0x23c3ab0: 0x23c3790,
---Type <return> to continue, or q <return> to quit---
this=0x2284b40) at staptree.h:992
#22 update_visitor::visit_block (this=0x2284b40, s=0x23c3be0)
at staptree.cxx:2571
#23 0x000000000045fba3 in require<statement> (clearok=false,
src=<optimized out>, this=0x2284b40) at staptree.h:970
#24 replace<statement> (clearok=false, src=@0x23c3870: 0x23c3be0,
this=0x2284b40) at staptree.h:992
#25 semantic_pass_symbols (s=...) at elaborate.cxx:1643
#26 0x000000000046c71c in semantic_pass (s=...) at elaborate.cxx:1985
#27 0x0000000000413c10 in passes_0_4 (s=...) at main.cxx:744
#28 0x000000000040c97b in main (argc=<optimized out>, argv=<optimized out>)
at main.cxx:1101
ENV:
stap --version
Systemtap translator/driver (version 2.4/0.157, commit
release-2.3-131-g1acfc03 + changes)
uname -a
Linux linux-6pwq.site 3.11.1-1.16-desktop+ #2 SMP PREEMPT Sun Oct 6
11:07:07 CST 2013 x86_64 x86_64 x86_64 GNU/Linux
any idea ?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: report a segment fault bug of systemtap
2013-12-28 11:52 report a segment fault bug of systemtap maliubiao
@ 2013-12-28 12:22 ` maliubiao
2014-01-11 18:10 ` Frank Ch. Eigler
1 sibling, 0 replies; 4+ messages in thread
From: maliubiao @ 2013-12-28 12:22 UTC (permalink / raw)
To: systemtap
more information:
I wrote a gdb script to trace this problem, and found this
.....
die_name 0x7ffff4367e63 "objs/ngx_modules.c"
cu_name 0x21eed88 "ngx_modules.c"
die_name 0x7ffff4367e86 "elf-init.c"
cu_name 0x21eed88 "ngx_modules.c"
die_name 0x7ffff43101b3 "../sysdeps/x86_64/crtn.S"
cu_name 0x21eed88 "ngx_modules.c"
die_name 0x0
cu_name 0x21eed88 "ngx_modules.c
then segment fault
dwarf_diename(cudie) returns a null pointer
SCRIPT:
import gdb
parse_and_eval = gdb.parse_and_eval
class dwarf_query_segv(gdb.Breakpoint):
def __init__(self):
super(dwarf_query_segv, self).__init__(
spec="tapsets.cxx:4192",
type = gdb.WP_READ,
wp_class = gdb.BP_READ_WATCHPOINT
)
def stop(self):
die_name = parse_and_eval("die_name")
cu_name = parse_and_eval("q->e.cu_name.c_str()")
print "die_name", str(die_name)
print "cu_name", str(cu_name)
dwarf_query_segv()
2013/12/28 maliubiao <maliubiao@gmail.com>:
> SCRIPT :
>
> global c = 0;
> probe process("/data/project/c/nginx-build/sbin/nginx").function("ngx_worker_process_cycle")
> {
> if (c < 1) {
> printf("%s\n", user_string($cycle->hostname->data))
> c += 1
> }
> }
>
> probe process("/data/project/c/nginx-build/sbin/nginx").function("ngx_epoll_process_events*")
> {
> /* iter over array ngx_modules */
> for (i=0; i < 512; i++) {
> index = @var("ngx_modules@ngx_modules.c")[i]->index
> if (index != i) {
> break
> }
> ngx_modules = @var("ngx_modules@ngx_modules.c")[i]
> ctx = @cast(ngx_modules, "ngx_module_s")->ctx
> name = @cast(ctx, "ngx_core_module_t")->name->data
> if (name) {
> printf("index: %s\n", i, user_string(name));
> }
> }
> }
>
> STACK TRACE:
>
> Pass 1: parsed user script and 100 library script(s) using
> 89752virt/29968res/2480shr/28316data kb, in 150usr/10sys/26180real ms.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff777e946 in __strcmp_sse42 () from /lib64/libc.so.6
> (gdb) bt
> #0 0x00007ffff777e946 in __strcmp_sse42 () from /lib64/libc.so.6
> #1 0x00000000004d57ad in dwarf_atvar_query::atvar_query_cu (cudie=0x24028a0,
> data=0x7fffffffba80) at tapsets.cxx:4192
> #2 0x000000000054a862 in dwflpp::iterate_over_cus (this=<optimized out>,
> callback=0x4d5760 <dwarf_atvar_query::atvar_query_cu(Dwarf_Die*, void*)>,
> data=0x7fffffffba80, want_types=false) at dwflpp.cxx:466
> #3 0x00000000004b48cd in query_module (mod=<optimized out>,
> name=<optimized out>, addr=4194304, arg=0x7fffffffba80) at tapsets.cxx:2132
> #4 0x00007ffff71edfa2 in dwfl_getmodules (dwfl=0x228cd60,
> callback=0x4b4770 <query_module(Dwfl_Module*, void**, char const*,
> Dwarf_Addr, void*)>, arg=0x7fffffffba80, offset=0)
> at ../.././elfutils-0.157/libdwfl/dwfl_getmodules.c:82
> #5 0x00000000004ca254 in dwarf_atvar_expanding_visitor::visit_atvar_op (
> this=0x2284b40, e=0x23c4030) at tapsets.cxx:4296
> #6 0x0000000000453fb3 in update_visitor::require<expression> (this=0x2284b40,
> src=<optimized out>, clearok=false) at staptree.h:970
> #7 0x00000000004c8e2b in replace<expression> (clearok=false,
> src=@0x23c3d88: 0x23c4030, this=0x2284b40) at staptree.h:992
> #8 var_expanding_visitor::rewrite_lvalue (this=this@entry=0x2284b40,
> tok=0x21eeaf0, eop="=", lvalue=@0x23c3d78: 0x23c3da0,
> rvalue=@0x23c3d88: 0x23c4030) at tapsets.cxx:2354
> #9 0x00000000004c9369 in var_expanding_visitor::visit_assignment (
> this=0x2284b40, e=0x23c3d60) at tapsets.cxx:2400
> ---Type <return> to continue, or q <return> to quit---
> #10 0x000000000044e1df in assignment::visit (this=0x23c3d60, u=0x2284b40)
> at staptree.cxx:1469
> #11 0x0000000000453fb3 in update_visitor::require<expression> (this=0x2284b40,
> src=<optimized out>, clearok=false) at staptree.h:970
> #12 0x000000000044c587 in replace<expression> (clearok=false,
> src=<optimized out>, this=0x2284b40) at staptree.h:992
> #13 update_visitor::visit_expr_statement (this=0x2284b40, s=0x23c3d40)
> at staptree.cxx:2599
> #14 0x000000000044a5bf in require<statement> (clearok=false,
> src=<optimized out>, this=0x2284b40) at staptree.h:970
> #15 replace<statement> (clearok=false, src=@0x23c3d00: 0x23c3d40,
> this=0x2284b40) at staptree.h:992
> #16 update_visitor::visit_block (this=0x2284b40, s=0x23c3cd0)
> at staptree.cxx:2571
> #17 0x0000000000453af3 in update_visitor::require<statement> (this=0x2284b40,
> src=<optimized out>, clearok=false) at staptree.h:970
> #18 0x000000000044cd8d in replace<statement> (clearok=false,
> src=@0x23c37b8: 0x23c3cd0, this=0x2284b40) at staptree.h:992
> #19 update_visitor::visit_for_loop (this=0x2284b40, s=0x23c3790)
> at staptree.cxx:2618
> #20 0x000000000044a5bf in require<statement> (clearok=false,
> src=<optimized out>, this=0x2284b40) at staptree.h:970
> #21 replace<statement> (clearok=false, src=@0x23c3ab0: 0x23c3790,
> ---Type <return> to continue, or q <return> to quit---
> this=0x2284b40) at staptree.h:992
> #22 update_visitor::visit_block (this=0x2284b40, s=0x23c3be0)
> at staptree.cxx:2571
> #23 0x000000000045fba3 in require<statement> (clearok=false,
> src=<optimized out>, this=0x2284b40) at staptree.h:970
> #24 replace<statement> (clearok=false, src=@0x23c3870: 0x23c3be0,
> this=0x2284b40) at staptree.h:992
> #25 semantic_pass_symbols (s=...) at elaborate.cxx:1643
> #26 0x000000000046c71c in semantic_pass (s=...) at elaborate.cxx:1985
> #27 0x0000000000413c10 in passes_0_4 (s=...) at main.cxx:744
> #28 0x000000000040c97b in main (argc=<optimized out>, argv=<optimized out>)
> at main.cxx:1101
>
> ENV:
> stap --version
> Systemtap translator/driver (version 2.4/0.157, commit
> release-2.3-131-g1acfc03 + changes)
> uname -a
> Linux linux-6pwq.site 3.11.1-1.16-desktop+ #2 SMP PREEMPT Sun Oct 6
> 11:07:07 CST 2013 x86_64 x86_64 x86_64 GNU/Linux
>
> any idea ?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: report a segment fault bug of systemtap
2013-12-28 11:52 report a segment fault bug of systemtap maliubiao
2013-12-28 12:22 ` maliubiao
@ 2014-01-11 18:10 ` Frank Ch. Eigler
2014-01-13 10:49 ` Mark Wielaard
1 sibling, 1 reply; 4+ messages in thread
From: Frank Ch. Eigler @ 2014-01-11 18:10 UTC (permalink / raw)
To: maliubiao; +Cc: systemtap
maliubiao wrote:
> [...]
> STACK TRACE:
>
> Pass 1: parsed user script and 100 library script(s) using
> 89752virt/29968res/2480shr/28316data kb, in 150usr/10sys/26180real ms.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff777e946 in __strcmp_sse42 () from /lib64/libc.so.6
> (gdb) bt
> #0 0x00007ffff777e946 in __strcmp_sse42 () from /lib64/libc.so.6
> #1 0x00000000004d57ad in dwarf_atvar_query::atvar_query_cu (cudie=0x24028a0,
> data=0x7fffffffba80) at tapsets.cxx:4192
> #2 0x000000000054a862 in dwflpp::iterate_over_cus (this=<optimized out>,
> callback=0x4d5760 <dwarf_atvar_query::atvar_query_cu(Dwarf_Die*, void*)>,
> data=0x7fffffffba80, want_types=false) at dwflpp.cxx:466
> [...]
> any idea ?
It seems like incomplete DWARF data can result in elfutils passing
NULL char*'s to the stap translator, which the latter is not always
prepared to tolerate. We encountered this same problem here yesterday
and committed a patch.
- FChE
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: report a segment fault bug of systemtap
2014-01-11 18:10 ` Frank Ch. Eigler
@ 2014-01-13 10:49 ` Mark Wielaard
0 siblings, 0 replies; 4+ messages in thread
From: Mark Wielaard @ 2014-01-13 10:49 UTC (permalink / raw)
To: Frank Ch. Eigler; +Cc: maliubiao, systemtap
On Sat, 2014-01-11 at 13:10 -0500, Frank Ch. Eigler wrote:
> It seems like incomplete DWARF data can result in elfutils passing
> NULL char*'s to the stap translator, which the latter is not always
> prepared to tolerate. We encountered this same problem here yesterday
> and committed a patch.
I quickly looked at the patch and I do think elfutils is allowed to
return NULL indeed. And you should guard against it.
dwarf_decl_file () will return NULL when there is no DW_AT_decl_file
attribute, if the value is zero (which indicates no source information
was recorded by the compiler) or if the .debug_line section isn't
valid/doesn't contain the indicated source file.
dwarf_diename () will return NULL when no DW_AT_name attribute can be
found (which isn't guaranteed to be produced by the compiler in all
cases). Or if the DW_AT_name is wrongly encoded (isn't a string).
In particular for CUs a DW_TAG_compile_unit often does have a name (the
primary source the compiler used), but a DW_TAG_partial_unit often
doesn't have one (since there it might be unclear whether there even is
a primary source file in that case).
Cheers,
Mark
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-01-13 10:49 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-28 11:52 report a segment fault bug of systemtap maliubiao
2013-12-28 12:22 ` maliubiao
2014-01-11 18:10 ` Frank Ch. Eigler
2014-01-13 10:49 ` Mark Wielaard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).