0004093: crash handler calls malloc()/free() - Dungeon Crawl Stone Soup Tracker

Viewing Issue Simple Details [ Jump to Notes ] [ Wiki ]

[ View Advanced ] [ Issue History ] [ Print ]

Category

Severity

Reproducibility

Date Submitted

Last Update

0004093

[DCSS] Bug Report

crash

have not tried

2011-06-03 01:31

2011-06-09 23:18

Reporter

KiloByte

View Status

public

Assigned To

KiloByte

Priority

normal

Resolution

done

Status

resolved

Product Branch

0.9 ancient branch

Summary

0004093: crash handler calls malloc()/free()

Description

A crash can happen at any point. This includes signal handlers (including pseudo-signals on Windows), and most libc functions are not signal-safe.

In particular, if malloc() was running, something nasty will happen. A deadlock, an infinite loop, anything. For example:
#0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:97
#1 0x00007f8498194f18 in _L_lock_9627 () from /lib/libc.so.6
0000002 0x00007f8498193301 in __libc_free (mem=0x7f849849ae60) at malloc.c:3736
0000003 0x00007f84989dea06 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::assign(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () from /usr/lib/libstdc++.so.6
0000004 0x0000000000a0a619 in message_item::operator= (this=0x1100d78) at message.cc:60
0000005 0x0000000000a0c138 in circ_vec<message_item, 1000>::push_back (this=0x10ff180, item=...) at message.cc:217
0000006 0x0000000000a0ba21 in message_store::store_msg (this=0x10ff180, msg=...) at message.cc:628
0000007 0x0000000000a0bbfb in message_store::flush_prev (this=0x10ff180) at message.cc:656
0000008 0x0000000000a09408 in flush_prev_message () at message.cc:1232
0000009 0x0000000000a09670 in get_last_messages (mcount=1000) at message.cc:1335
0000010 0x000000000078d8ca in do_crash_dump () at dbg-asrt.cc:640
0000011 0x0000000000ca87cd in _crash_signal_handler (sig_num=15) at crash-u.cc:121
0000012 <signal handler called>
0000013 _int_free (av=0x7f849849ae60, p=0x2f815c0) at malloc.c:5072
0000014 0x00007f849819330c in __libc_free (mem=<value optimized out>) at malloc.c:3738
0000015 0x00007f84989dd623 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() ()
from /usr/lib/libstdc++.so.6
0000016 0x0000000000c21302 in CrawlHashTable::assert_validity (this=0x102cde8) at store.cc:1369
0000017 0x0000000000c21029 in CrawlHashTable::exists (this=0x102cde8, key=...) at store.cc:1345
0000018 0x0000000000a5a74c in monster_info::monster_info (this=0x7fff7a345f70, m=0x102cdd0, milev=-1) at mon-info.cc:237
[...]

I wonder what we can do. Carefully avoiding all forbidden functions would make writing the crash dump a good deal harder (like, no C++ string functions...), so I guess an unclean pragmatic solution like alarm() to kill the process in case of a lock-up could be the best. Too bad, there's no such function on Windows. Does someone have a good idea how to proceed?

Additional Information

Notes
(0013442) KiloByte (manager) 2011-06-09 23:18	I implemented alarm() on Windows, hope this will be enough.

Issue History
Date Modified	Username	Field	Change
2011-06-03 01:31	KiloByte	New Issue
2011-06-09 23:18	KiloByte	Note Added: 0013442
2011-06-09 23:18	KiloByte	Status	new => resolved
2011-06-09 23:18	KiloByte	Fixed in Branch	=> 0.9 development branch
2011-06-09 23:18	KiloByte	Resolution	open => done
2011-06-09 23:18	KiloByte	Assigned To	=> KiloByte

Relationships