Changes between Version 4 and Version 5 of Ticket #9858, comment 25


Ignore:
Timestamp:
Jul 9, 2014, 5:40:00 PM (10 years ago)
Author:
ttcoder

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #9858, comment 25

    v4 v5  
    88- look into answering the question [https://dev.haiku-os.org/ticket/8376#comment:6 here] though I have no idea if I've touched something important or completely benign there..
    99- review #10259, which has a good description of the "text string as pointer" lead that I'm following in priority.
    10 - the current/best lead that I have on solving the text-string-as-pointer crash is not in 10259 , but instead it starts with [https://dev.haiku-os.org/ticket/9528#comment:8 this comment] and further down. I'll look into it as time permits. I'll e.g. completely disable free()/delete calls throughout kernel_interface.cpp, in case the KDL is caused by a heap corruption after a double-free. Or maybe the string is copied into system structures (talking of the CD's label/name here), so I'll hack a custom version of Volume::Name() that returns a sequential number (cd01, cd02) each time it's called, to determine ''which'' copy ends up in the KDL screen into the edx register..
     10- the current/best lead that I have on solving the text-string-as-pointer crash is not in 10259 , but instead it starts with [https://dev.haiku-os.org/ticket/9528#comment:8 this comment] and further down. I'll look into it as time permits. I'll e.g. completely disable free()/delete calls throughout kernel_interface.cpp, in case the KDL is caused by a heap corruption after a double-free. Or maybe the string is copied into system structures (talking of the CD's label/name here), so I'll hack a custom version of Volume::Name() that returns a sequential number (cd01, cd02) each time it's called, to determine ''which'' copy ends up in the KDL screen into the edx register.. INdeed, currently if Name() returns 7a7a7a7a7a.. then that "address" ends up displayed in the KDL screen, but Name() is called several times so it will be itneresting to know ''which'' call starts off the chain of destruction..
    1111
    12 The closest I have to a reproducible case BTW, is opening/closing the (Tracker) window of the AudioCD as it's being concurrently accessed from another application, hence the attributes being read/Written with time pressure.
     12The closest I have to a reproducible case BTW, is opening/closing the (Tracker) window of the AudioCD as it's being concurrently accessed from another application, hence the attributes being read/Written with time pressure, some sort of race condition.
    1313
    1414My intuition is that the heap corruption occurs at that time, as "cookies" are allocated for accessing attributes. In the syslog with my extra tracing I  can see that there are "cross-overs" between free_cookie() and allocate_cookie(), maybe the code is getting confused there.. esp. confused with regard to the fName label that ends up being interpreted as a pointer instead of a text string.. Dunno. I'm not nearly skilled enough to debug this efficiently.