Opened 6 years ago

Last modified 5 years ago

#14376 new bug

Heap corruption after AreaTest is run

Reported by: KapiX Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: - General Version: R1/Development
Keywords: Cc: ttcoder
Blocked By: Blocking: #12442, #12800
Platform: All

Description

AreaTest is part of our test suite for Media Kit. [1]

It's fairly simple but has disastrous effect on memory. BApplication tests crash in hoard later. If it is disabled, everything is fine.

Minimal reproducer:

Add AreaTest contents to TBApplicationTester::BApplication1() at the beginning and merge TBApplicationTester::BApplication2() with it so that they are one test case. [2]

It can also be reproduced by running UnitTester with [3] applied (and AreaTest enabled). It should crash in QuitTest or BApplicationTest.

I suspect it's a VM subsystem issue - clone_area is not used a lot in Haiku (if GitHub search is to be believed only accelerants, BBitmaps and Media Kit use it).

I tried to debug, but did not get very far:

the crash happens when hoard is traversed, for example here [4]. chunk->next is a bogus value (in my tests 0x09090808 - this one surrounded by other bogus stuff, 0x22 or 0x2222222 - these look like some memory write didn't go where it should).

[1] https://git.haiku-os.org/haiku/tree/src/tests/kits/media/AreaTest.cpp

[2] https://git.haiku-os.org/haiku/tree/src/tests/kits/app/bapplication/BApplicationTester.cpp#n55

[3] https://review.haiku-os.org/c/haiku/+/465

[4] https://git.haiku-os.org/haiku/tree/src/system/libroot/posix/malloc/arch-specific.cpp#n159

Attachments (1)

hoarddebug.png (183.1 KB ) - added by KapiX 6 years ago.

Download all attachments as: .zip

Change History (11)

by KapiX, 6 years ago

Attachment: hoarddebug.png added

comment:1 by KapiX, 6 years ago

BApplication tests use pipes a lot and most of the crashes happen there (in popen for example).

comment:2 by CodeforEvolution, 5 years ago

Since we’re talking about memory and heap corruption anyway, I’d like to bring up that our current memory allocator, hoard, has been written up in articles as inefficient with memory compared to competitors such as jemalloc. Maybe a future todo could be replacing hoard? Maybe even a GSoC task depending?

comment:3 by ttcoder, 5 years ago

Cc: ttcoder added

in reply to:  2 comment:4 by korli, 5 years ago

Replying to CodeforEvolution:

Since we’re talking about memory and heap corruption anyway, I’d like to bring up that our current memory allocator, hoard, has been written up in articles as inefficient with memory

It seems to me like you didn't search too long before posting such a comment. #13554

comment:5 by CodeforEvolution, 5 years ago

Ah, sorry about that, didn't see that ticket.

comment:6 by waddlesplash, 5 years ago

Blocking: 12442 added

comment:7 by waddlesplash, 5 years ago

KapiX, now that we've switched to rpmalloc, can you look into this one again?

comment:8 by waddlesplash, 5 years ago

Blocking: 12800 added

comment:9 by KapiX, 5 years ago

I have run the entire test suite and it still crashes in malloc (NetworkUrlTest), but it's way farther and disabling AreaTest doesn't seem to affect it. I guess there is a heap corruption somewhere else in the tests.

comment:10 by waddlesplash, 5 years ago

It would still be nice to see if there actually is some clone area bug that AreaTest was somehow hitting. But maybe that's impossible.

Note: See TracTickets for help on using tickets.