Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Segfault when saving large projects (sort stack exhaustion) #7079

Closed
GovanifY opened this issue Mar 20, 2017 · 23 comments
Closed

Segfault when saving large projects (sort stack exhaustion) #7079

GovanifY opened this issue Mar 20, 2017 · 23 comments
Assignees
@alvarofe
Labels
projects Loading, saving and handling radare2 project files RAnal
Milestone
1.4.0

Comments

@GovanifY
Copy link
Contributor

GovanifY commented Mar 20, 2017 •
edited
Loading

Yo,
I tried to save a project based on a large project I just analysed and got a segfault
To clear what I mean by large I mean radare had 500-600.000kb of heap before the segfault.
The binary in question cannot be shared due to licensing contrains but for anyone that have a Nintendo Switch dumping any nro that is a bit large should do it(WebKit ought to be perfect even tho it was not the binary I was studying).

All I did was

aaa
Ps switch_secret

and it crashed.
xrefs.db seems to be saved(albeit unsure if fully, it is 100mb big) and rc was saved until meta(ie it ends with # meta)

Thanks for that, as waiting a hour to reach an analyse finished and seeing a segfault is always funny =D
(don't take it agressively, I just spent the whole day mindlessly rebooting my switch and poking at svcs before seeing my dump crashed, so it was kinda raging when it happened)

Thanks for the hard work!
P.S: I am running gdb but radare taking a good time before even finishing to analyze the binary don't expect a backtrace before 1/2h(old thinkpad there)
P.S.2:3h after, still analyzing(running two r2 threads because I still need to work on it fu)
@Maijin Maijin added bug projects Loading, saving and handling radare2 project files RAnal labels Mar 20, 2017
@GovanifY
Copy link
Contributor Author

Sorry for the delays, had things to do.
I tried on the webkit this time to allow easy debugging, issue is indeed related to size

Here's the backtrace

[0x01676d94]> Ps switch_webkit

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff41e8682 in __cmp_asc (a=<error reading variable: Cannot access memory at address 0x7fffff7feff8>, 
    b=<error reading variable: Cannot access memory at address 0x7fffff7feff0>) at sdb.c:634
634     static int __cmp_asc(const void *a, const void *b) {
(gdb) bt
#0  0x00007ffff41e8682 in __cmp_asc (a=<error reading variable: Cannot access memory at address 0x7fffff7feff8>, 
    b=<error reading variable: Cannot access memory at address 0x7fffff7feff0>) at sdb.c:634
#1  0x00007ffff41e27e9 in _merge (first=0x55555fad43d0, second=0x555567598ff0, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:44
#2  0x00007ffff41e2850 in _merge (first=0x55555ea751e0, second=0x555567598ff0, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:50
#3  0x00007ffff41e2850 in _merge (first=0x555561279330, second=0x555567598ff0, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:50
#4  0x00007ffff41e2808 in _merge (first=0x555561279330, second=0x5555568ef830, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#5  0x00007ffff41e2850 in _merge (first=0x55555d58fde0, second=0x5555568ef830, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:50
#6  0x00007ffff41e2850 in _merge (first=0x555560ccffe0, second=0x5555568ef830, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:50
#7  0x00007ffff41e2808 in _merge (first=0x555560ccffe0, second=0x555558c71840, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#8  0x00007ffff41e2808 in _merge (first=0x555560ccffe0, second=0x555562db99b0, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#9  0x00007ffff41e2808 in _merge (first=0x555560ccffe0, second=0x55555c6a23d0, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#10 0x00007ffff41e2808 in _merge (first=0x555560ccffe0, second=0x555567b84f50, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#11 0x00007ffff41e2808 in _merge (first=0x555560ccffe0, second=0x555567b7b850, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#12 0x00007ffff41e2808 in _merge (first=0x555560ccffe0, second=0x55555b264190, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#13 0x00007ffff41e2850 in _merge (first=0x555561bbdad0, second=0x55555b264190, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:50
#14 0x00007ffff41e2850 in _merge (first=0x555566b7ac40, second=0x55555b264190, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:50
#15 0x00007ffff41e2850 in _merge (first=0x555564e5bc90, second=0x55555b264190, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:50
#16 0x00007ffff41e2850 in _merge (first=0x55555cecd4a0, second=0x55555b264190, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:50
#17 0x00007ffff41e2850 in _merge (first=0x555560940330, second=0x55555b264190, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:50
#18 0x00007ffff41e2850 in _merge (first=0x555560c8cbc0, second=0x55555b264190, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:50
#19 0x00007ffff41e2850 in _merge (first=0x5555668d1520, second=0x55555b264190, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:50
#20 0x00007ffff41e2808 in _merge (first=0x5555668d1520, second=0x5555589cc170, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#21 0x00007ffff41e2850 in _merge (first=0x5555679360f0, second=0x5555589cc170, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:50
#22 0x00007ffff41e2850 in _merge (first=0x555563ba5090, second=0x5555589cc170, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:50
#23 0x00007ffff41e2808 in _merge (first=0x555563ba5090, second=0x55555a28d950, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#24 0x00007ffff41e2808 in _merge (first=0x555563ba5090, second=0x555558468d70, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#25 0x00007ffff41e2808 in _merge (first=0x555563ba5090, second=0x55555b6fcb70, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#26 0x00007ffff41e2808 in _merge (first=0x555563ba5090, second=0x55555cfdfa20, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#27 0x00007ffff41e2808 in _merge (first=0x555563ba5090, second=0x55555d61c4c0, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#28 0x00007ffff41e2808 in _merge (first=0x555563ba5090, second=0x555563010390, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#29 0x00007ffff41e2808 in _merge (first=0x555563ba5090, second=0x555560cbc450, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#30 0x00007ffff41e2808 in _merge (first=0x555563ba5090, second=0x5555686b1930, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#31 0x00007ffff41e2808 in _merge (first=0x555563ba5090, second=0x555560640d70, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#32 0x00007ffff41e2808 in _merge (first=0x555563ba5090, second=0x555559789cf0, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#33 0x00007ffff41e2808 in _merge (first=0x555563ba5090, second=0x55555dc73290, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#34 0x00007ffff41e2808 in _merge (first=0x555563ba5090, second=0x5555573d7750, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#35 0x00007ffff41e2808 in _merge (first=0x555563ba5090, second=0x5555643c1b40, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#36 0x00007ffff41e2808 in _merge (first=0x555563ba5090, second=0x55556672aaa0, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#37 0x00007ffff41e2808 in _merge (first=0x555563ba5090, second=0x555562c554d0, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#38 0x00007ffff41e2808 in _merge (first=0x555563ba5090, second=0x555568ae2f20, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#39 0x00007ffff41e2808 in _merge (first=0x555563ba5090, second=0x55555d9764c0, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#40 0x00007ffff41e2808 in _merge (first=0x555563ba5090, second=0x55555b3ab3a0, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#41 0x00007ffff41e2850 in _merge (first=0x55555da76df0, second=0x55555b3ab3a0, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:50
#42 0x00007ffff41e2850 in _merge (first=0x55556268ea00, second=0x55555b3ab3a0, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:50
#43 0x00007ffff41e2808 in _merge (first=0x55556268ea00, second=0x555561709d30, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#44 0x00007ffff41e2808 in _merge (first=0x55556268ea00, second=0x55555af506a0, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#45 0x00007ffff41e2808 in _merge (first=0x55556268ea00, second=0x55555808f020, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#46 0x00007ffff41e2808 in _merge (first=0x55556268ea00, second=0x5555646b4440, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#47 0x00007ffff41e2808 in _merge (first=0x55556268ea00, second=0x555558475eb0, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#48 0x00007ffff41e2808 in _merge (first=0x55556268ea00, second=0x555564b1ef30, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#49 0x00007ffff41e2808 in _merge (first=0x55556268ea00, second=0x55555edb5c00, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#50 0x00007ffff41e2808 in _merge (first=0x55556268ea00, second=0x555566bba980, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
#51 0x00007ffff41e2850 in _merge (first=0x555567eab130, second=0x555566bba980, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:50
#52 0x00007ffff41e2850 in _merge (first=0x55555e302190, second=0x555566bba980, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:50
#53 0x00007ffff41e2850 in _merge (first=0x5555681f5320, second=0x555566bba980, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:50
#54 0x00007ffff41e2850 in _merge (first=0x55556202e140, second=0x555566bba980, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:50
#55 0x00007ffff41e2850 in _merge (first=0x5555647850a0, second=0x555566bba980, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:50
#56 0x00007ffff41e2850 in _merge (first=0x5555649b2ea0, second=0x555566bba980, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:50
#57 0x00007ffff41e2808 in _merge (first=0x5555649b2ea0, second=0x55555f4dc640, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:45
...snip...
#39224 0x00007ffff41e2850 in _merge (first=0x5555609a4ed0, second=0x55555f6509e0, cmp=0x7ffff41e867a <__cmp_asc>) at ls.c:50

it goes on and on but I'mm too lazy to check the end.
I'm keeping the gdb session open if anyone needs other infos(or if I actually fix it)

@radare
Copy link
Collaborator

radare commented Mar 21, 2017 via email

@alvarofe
Copy link
Contributor

which is your r2's version?. I added a thing to avoid this, may not been working though. We should change to another algorithm to avoid such issue and hacks to get around it.

@Maijin
Copy link
Contributor

Maijin commented Mar 21, 2017

Hello,

Ensure you are using radare2 from git, if you're unsure paste output of r2 -v here.
To install radare2 from git, first uninstall your version of radare2 and clean your distro. Then use git clone https://github.com/radare/radare2 && cd radare2 && ./sys/install.sh, verify your version and check if there is no error using r2 -v.

@GovanifY
Copy link
Contributor Author

I have radare from git, otherwise I wouldn't have nintendo switch nro support.
radare2 1.4.0-git 14139 @ linux-x86-64 git.1.3.0-105-gca0c4908d
commit: ca0c490 build: 2017-03-20__14:37:52

@GovanifY GovanifY changed the title Segfault when saving large projects (rc meta-struct related?) Segfault when saving large projects (sort stack exhaustion) Mar 21, 2017
@radare radare added this to the 1.4.0 milestone Mar 21, 2017
@radare radare added the release label Mar 21, 2017
@radare
Copy link
Collaborator

radare commented Mar 21, 2017 via email

@radare
Copy link
Collaborator

radare commented Mar 23, 2017

will be good to have a way to reproduce this, maybe a unit test in sdb?

@GovanifY
Copy link
Contributor Author

GovanifY commented Mar 24, 2017 •
edited
Loading

Sorry, was unsure if you actually talked to me. I am unsure how to reproduce this as the binary is tooked from a memory dump of the nintendo switch(don't think you'll wish to be in a legal grey area) and it takes a VERY long time to process.
I guess any big binaries should do it tho, just try Ps after having done an aaa

@radare
Copy link
Collaborator

radare commented Mar 24, 2017 via email

@GovanifY
Copy link
Contributor Author

Got the unit test. Will do a pull commit in a few on radare2-regressions

@Maijin
Copy link
Contributor

Maijin commented Mar 24, 2017

Here for the sdb test ->https://github.com/radare/sdb/tree/master/test

@GovanifY
Copy link
Contributor Author

Just seen the sdb comment. Oh well. Should I still move it to sdb or keep it in regressions?

@GovanifY
Copy link
Contributor Author

As another note I might have messed up the unit test as it receives a SIGKILL and not a segfault. I don't think it's an out of memory issue for me but it is still weird nonetheless

@GovanifY GovanifY mentioned this issue Mar 24, 2017
Closed
@GovanifY
Copy link
Contributor Author

There we go, and a segfault

@alvarofe
Copy link
Contributor

Fixed in r2 and sdb. Reopen again if is not fixed but testing here I couldn't reproduce it anymore.

@GovanifY
Copy link
Contributor Author

govanify@ThinkPadW500 ~/ $ r2 -v
radare2 1.4.0-git 14209 @ linux-x86-64 git.1.3.0-175-gb6b1b3e18
commit: b6b1b3e build: 2017-03-26__23:37:15
Got a segfault with this version, re-emerging(gentoo, from git master) just in case and launching gdb to get the backtrace

@alvarofe
Copy link
Contributor

Did you bump sdb into master? The fix in sdb has not been merged yet. Will be done tonight

@alvarofe
Copy link
Contributor

Did you test the code in sdb with the unit test you wrote?

@GovanifY
Copy link
Contributor Author

Hey, nope, just merged from master using gentoo ebuild. If the fix has not been merged yet I don't think it has been updated. I'll retry once done, thanks!

@alvarofe
Copy link
Contributor

Test now please, sdb has been merged now, I hope is fixed.

@GovanifY
Copy link
Contributor Author

sure, lemme compile and retry(inb4 no response before few hours)

@GovanifY
Copy link
Contributor Author

It seems to work, so issue fixed that is! Thanks for the support once again

@alvarofe
Copy link
Contributor

glad to hear that :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@alvarofe alvarofe

Labels
projects Loading, saving and handling radare2 project files RAnal
Projects
None yet
Milestone
1.4.0
Development

No branches or pull requests
4 participants
@radare @Maijin @alvarofe @GovanifY