Project

General

Profile

Bug #3992

mdb ::stacks segv

Added by Josef Sipek over 6 years ago. Updated over 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
mdb - modular debugger
Start date:
2013-08-05
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:

Description

Suppose you have a simple program:

int main(int argc, char **argv)
{
    return 0;
}

And you decide to use mdb's ::stacks on it:

$ mdb ./test
> ::load libc
> ::sysbp _exit
> :r
mdb: stop on entry to _exit
mdb: target stopped at:
0xfee71578:     nop    
> ::stacks
THREAD   STATE    SOBJ        COUNT
1        UNPARKED <NONE>          1

> :c
mdb: target has terminated
> ::stacks
mdb: failed to iterate over threads: libthread_db call failed unexpectedly
mdb: cannot walk "thread": failed to initialize walk
free(812eb88): double-free or invalid buffer
stack trace:
libumem.so.1'umem_err_recoverable+0x3f
libumem.so.1'process_free+0xe4
libumem.so.1'free+0x1a
mdb'mdb_free+0x3f
libc.so'stacks_cleanup+0xe5
libc.so'stacks_dcmd+0x2e
mdb'dcmd_invoke+0x4e
mdb'mdb_call_idcmd+0x134
mdb'mdb_call+0x32e
mdb'yyparse+0x473
mdb'mdb_run+0x2eb
mdb'main+0x139d
mdb'_start+0x7d

*** mdb: received signal ABRT at:
    [1] libc.so.1`_lwp_kill+0x15()
    [2] libc.so.1`raise+0x22()
    [3] libumem.so.1`umem_do_abort+0x2e()
    [4] libumem.so.1`umem_err_recoverable+0x4f()
    [5] libumem.so.1`process_free+0xe4()
    [6] libumem.so.1`free+0x1a()
    [7] mdb`mdb_free+0x3f()
    [8] libc.so`stacks_cleanup+0xe5()
    [9] libc.so`stacks_dcmd+0x2e()
    [10] mdb`dcmd_invoke+0x4e()
    [11] mdb`mdb_call_idcmd+0x134()
    [12] mdb`mdb_call+0x32e()
    [13] mdb`yyparse+0x473()
    [14] mdb`mdb_run+0x2eb()
    [15] mdb`main+0x139d()
    [16] mdb`_start+0x7d()

mdb: (c)ore dump, (q)uit, (r)ecover, or (s)top for debugger [cqrs]? 

As you can see, libumem wasn't happy. It looks like improper error handling (the thread walk errored out leaving an allocated buffer hanging around).

History

#1

Updated by Josef Sipek over 6 years ago

  • % Done changed from 30 to 50

It turns out that the stacks_hash/stacks_array may get freed multiple times if stacks_state stays as STACKS_STATE_DIRTY due to an error.

#2

Updated by Robert Mustacchi over 6 years ago

  • Category set to mdb - modular debugger
  • % Done changed from 50 to 100
  • Tags deleted (needs-triage)

Resolved in 98144673ce45bddc6d5dbe7e2afab720c660b5d7.

#3

Updated by Robert Mustacchi over 6 years ago

  • Status changed from New to Resolved

Also available in: Atom PDF