mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-11-04 22:07:27 +00:00
0b8b3ba21e
This is likely only the tip of the ice berg, but this particular bug caused any double-free on a glibc system to turn into a deadlock! It is not generally safe to either allocate or release heap memory from within the signal handler. The 'pop_back()' in RemoveFilesToRemove was deleting memory and causing the deadlock. What's worse, eraseFromDisk in PathV1 has lots of allocation and deallocation paths. We even passed 'true' in a place that would have caused the *signal handler* to try to run the 'system' system call and shell out to 'rm -rf'. That was never going to work... This patch switches the file removal to use a vector of strings so that the exact text needed for the 'unlink' system call can be stored there. It switches the loop to be a boring indexed loop, and directly calls unlink without looking at the error. It also works quite hard to ensure that calling 'c_str()' is safe, by ensuring that the non-signal-handling code path that manipulates the vector always leaves it in a state where every element has already had 'c_str()' called at least once. I dunno exactly how overkill this is, but it fixes the deadlock-on-double free issue, and seems likely to prevent any other issues from sneaking up. Sorry for not having a test case, but I *really* don't know how to test signal handling code easily.... git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158580 91177308-0d34-0410-b5e6-96231b3b80d8 |
||
|---|---|---|
| .. | ||
| Host.inc | ||
| Memory.inc | ||
| Mutex.inc | ||
| Path.inc | ||
| PathV2.inc | ||
| Process.inc | ||
| Program.inc | ||
| README.txt | ||
| RWMutex.inc | ||
| Signals.inc | ||
| system_error.inc | ||
| ThreadLocal.inc | ||
| TimeValue.inc | ||
| Unix.h | ||
llvm/lib/Support/Unix README =========================== This directory provides implementations of the lib/System classes that are common to two or more variants of UNIX. For example, the directory structure underneath this directory could look like this: Unix - only code that is truly generic to all UNIX platforms Posix - code that is specific to Posix variants of UNIX SUS - code that is specific to the Single Unix Specification SysV - code that is specific to System V variants of UNIX As a rule, only those directories actually needing to be created should be created. Also, further subdirectories could be created to reflect versions of the various standards. For example, under SUS there could be v1, v2, and v3 subdirectories to reflect the three major versions of SUS.