Opened 14 months ago

Last modified 5 months 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
Has a Patch: no 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 14 months ago.

Download all attachments as: .zip

Change History (11)

by KapiX, 14 months ago

Attachment: hoarddebug.png added

comment:1 by KapiX, 14 months ago

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

comment:2 by CodeforEvolution, 10 months 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, 10 months ago

Cc: ttcoder added

in reply to:  2 comment:4 by korli, 10 months 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, 10 months ago

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

comment:6 by waddlesplash, 10 months ago

Blocking: 12442 added

comment:7 by waddlesplash, 5 months ago

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

comment:8 by waddlesplash, 5 months ago

Blocking: 12800 added

comment:9 by KapiX, 5 months 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 months 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.