Yes, you are correct, that line is buggy and contains a typo. I added it later in a hurry after I could reproduce the error, to ensure a clean shutdown of the script. What I meant to type was:
> trap "kill $!; exit 0" INT TERM However thinking about it, this also does not work as intended. The problem exists, though, even if that line is deleted (one just has to kill all remaining threads manually after the crash or after ^C). If you need, I can update the script with a INT and TERM handler, which actually kills, however since this is not relevant to the problem in question, I did not sent a correction after I noticed the typo. I am also aware of the strict restrictions on operations allowed during signal handling in C and C++. I tried to find any documentation on allowed operations during trap handlers for bash, but even after a prolonged search in the man and info pages as well as online, I could not find an resources on that topic. The low number of responses to the same question on SO also seems to show, that hardly anyone is aware of such restrictions. If such documentation exists of course this is not bug. In that case my personal suggestion would be to somehow mention the available documentation in the man pages. This would be especially usefull, since it is not very clear, what operations would need a malloc() internally (note that in C most kinds of exec() do malloc() and therefore are not thread safe, however executing external commands is very common in bash, so the restrictions cannot just be derived from the C-side). I also noted, that the behaviour is different from problems during signal handling. The most likely result of a forbidden operation during signal handling would be a deadlock (since the operation will try to lock the same resource twice in the same thread). However in this case somehow the parser seems to mess up it's internal state, resulting in the parser error I am seeing. I hope this makes the problem more clear. Thank you for your feedback, Till -----Ursprüngliche Nachricht----- Von: Bob Proulx [mailto:b...@proulx.com] Gesendet: Donnerstag, 3. Mai 2012 09:08 An: Crueger, Tillmann Cc: bug-bash@gnu.org Betreff: Re: Possible bug: Race condition when calling external commands during trap handling tillmann.crue...@telekom.de wrote: > I have produced the following script as a small example: A good small example! I do not understand the problem but I do have a question about one of the lines in it and a comment about another. > trap "kill $?; exit 0" INT TERM What did you intend with "kill $?; exit 0"? Did you mean "kill $$" instead? > local text="$(date +'%Y-%m-%d %H:%M:%S') $(hostname -s) $1" Note that GNU date can use "+%F %T" as a shortcut for "%Y-%m-%d %H:%M:%S". It is useful to save typing. And lastly I will comment that you are doing quite a bit inside of an interrupt routine. Typically in a C program it is not safe to perform any operation that may call malloc() within an interupt service routine since malloc isn't reentrant. Bash is a C program and I assume the same restriction would apply. Bob
