[haiku-bugs] Re: [Haiku] #9858: Ripping CDs -> page fault panic
- From: "ttcoder" <trac@xxxxxxxxxxxx>
- Date: Wed, 12 Nov 2014 18:54:20 -0000
#9858: Ripping CDs -> page fault panic
---------------------------------+----------------------------
Reporter: ttcoder | Owner: nobody
Type: bug | Status: assigned
Priority: high | Milestone: R1/beta1
Component: File Systems/cdda | Version: R1/Development
Resolution: | Keywords: slab
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
---------------------------------+----------------------------
Comment (by ttcoder):
1- I've put dsuden on the case, my Grand Fromage is much better than me at
triggering the KDL, he can do it in 3 runs of tuneprepper when it takes me
10 or more, we'll have news soon hopefully :-)
2- A moderately-strong [https://dev.haiku-os.org/ticket/9528#comment:9
suggestion] from me, that might get you closer to the guilty party:
{{{
Volume::~Volume()
{
...
+ memset(fName, 'z', strlen(fName));
free(fName);
}
}}}
Recompile cdda with that memset() in; the change is harmless in itself, in
that it will not turn correct code into incorrect code: it is legit to
write whatever one wants in a const char* buffer before returning it to
the system. The interest lies in the fact that the written string
sometimes does end up in the KDL message.. (address 0x7a7a7a7a, ascii for
"zzzz"). ! It'd be interesting if that is true in your testing as well as
in mine.
Anyway that suggestion is based on the assumption that knowing which
variable [ 's contents] contains the corrupting buffer, is useful in
identifying the code that is guilty of copying that contents into a wild
place. Maybe one does not lead to the other and that assumption is wrong
though..
(does kernelland have anything like the "watch-point" feature in userland
debugger, to detect when a write occurs into a memory area?)
--
Ticket URL: <https://dev.haiku-os.org/ticket/9858#comment:28>
Haiku <https://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
