Changes between Initial Version and Version 1 of Ticket #9858, comment 25


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

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #9858, comment 25

    initial v1  
    66
    77R&D/head banging on my todolist, or for anyone with thte spare time:
    8 - review #10259, which a gooddescription of the "text string as pointer" lead that I'm following in priority.
    9 - look into answering the question [https://dev.haiku-os.org/ticket/8376#comment:6 here]
    10 - the current/best lead that I have, 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.
     8- review #10259, which has a good description of the "text string as pointer" lead that I'm following in priority.
     9- 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..
     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 DetermineName() 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..
    1111
    12 The closest I have to a reproducible case BTW, is opening/closing the (Tracker) window of the AudioCD as it's being mounted. My 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..
     12The closest I have to a reproducible case BTW, is opening/closing the (Tracker) window of the AudioCD as it's being mounted. My 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.
    1313
     14