Bug 1015419

Summary:	For scripted use, "disassemble" command needs sanity size limiting
Product:	[Fedora] Fedora	Reporter:	Denys Vlasenko <dvlasenk>
Component:	gdb	Assignee:	Phil Muldoon <pmuldoon>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	gbenson, jan.kratochvil, palves, pmuldoon, sergiodj, tromey
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-10-04 08:34:24 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Denys Vlasenko 2013-10-04 08:02:53 UTC

We have a user report where coredump contains $pc pointing into .bss

gdb "disassemble", consequently, tries to disassemble *entire* .bss.

Since it is done by automated gdb run (gdb -batch -ex disassemble),
there is no user at the keyboard who can realize that this isn't useful
and can produce many megabytes of output.

Please add a parameter or an option to "disassemble" command
which can be used to cap the output size. Something along the lines of

(gdb) disassemble /maxlines:20000

Comment 1 Jan Kratochvil 2013-10-04 08:34:24 UTC

Such simple usage is really scriptable with Python.  For example first 3 lines:

(gdb) python import re;print re.compile("^([^\n]*\n){3}").match(gdb.execute("disassemble main",False,True)).group()

Comment 2 Denys Vlasenko 2013-10-04 10:09:26 UTC

(In reply to Jan Kratochvil from comment #1)
> Such simple usage is really scriptable with Python.  For example first 3
> lines:
> 
> (gdb) python import re;print
> re.compile("^([^\n]*\n){3}").match(gdb.execute("disassemble
> main",False,True)).group()

See bug 995889:

"""
Generating core_backtrace
Lock file './.lock' is locked by process 6567
Generating backtrace
Backtrace is too big (33564131 bytes), reducing depth to 512
Backtrace is too big (33564131 bytes), reducing depth to 256
Backtrace is too big (33564131 bytes), reducing depth to 128
etc.

The backtrace never decreases in size and I am unable to submit the bug. On a Core-i7, it is very slow and can easily take 30+ minutes to run through the gamut before giving up. 
"""

IOW: the execution time and possible memory exhaustion temporarily storing megabytes of disasm is also the problem here.

Comment 3 Jan Kratochvil 2013-10-04 12:31:02 UTC

disassemble main,+20000

Just it is in bytes and not lines but that should not matter much.

Comment 4 Jan Kratochvil 2013-10-04 12:32:05 UTC

oops, not right, it does not stop at the end of main.

Comment 5 Jan Kratochvil 2013-10-04 12:54:08 UTC

This one should work:


import re
f="main"
l=1
r=20000
# Is there \Q in Python?
p=re.compile("^%s [+] "%f)
while l<r:
    m=(l+r)/2
    if p.match(gdb.execute("info symbol %s+%d"%(f,m),False,True)):
        l=m+1
    else:
        r=m
gdb.execute("disassemble %s,+%d"%(f,r))