Opened 11 months ago

Last modified 8 weeks 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 11 months ago.

Download all attachments as: .zip

Change History (11)

Changed 11 months ago by KapiX

Attachment: hoarddebug.png added

comment:1 Changed 11 months ago by KapiX

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

comment:2 Changed 7 months ago by 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 compared to competitors such as jemalloc. Maybe a future todo could be replacing hoard? Maybe even a GSoC task depending?

comment:3 Changed 7 months ago by ttcoder

Cc: ttcoder added

comment:4 in reply to:  2 Changed 7 months ago by korli

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 Changed 7 months ago by CodeforEvolution

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

comment:6 Changed 7 months ago by waddlesplash

Blocking: 12442 added

comment:7 Changed 2 months ago by waddlesplash

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

comment:8 Changed 2 months ago by waddlesplash

Blocking: 12800 added

comment:9 Changed 8 weeks ago by KapiX

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 Changed 8 weeks ago by waddlesplash

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.