Skip to main content ↑ ↓
Topic: Exciting new crash. (Read 5476 times) previous topic - next topic

Exciting new crash.

This time on loading a savegame.

Code: [Select]
FATAL ERROR: sim_new_handler()
Error allocating new object


Program received signal SIGABRT, Aborted.
0xb7fff424 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7fff424 in __kernel_vsyscall ()
#1  0x45bb58e0 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0x45bb8e15 in *__GI_abort () at abort.c:88
#3  0x08275880 in log_t::fatal (this=0x83d97e0, who=0x82c6614 "sim_new_handler()", 
    format=0x82c65f8 "Error allocating new object") at utils/log.cc:243
#4  0x082151a0 in sim_new_handler () at simmain.cc:316
#5  0x461cc17a in operator new(unsigned int) () from /usr/lib/libstdc++.so.6
#6  0x461cc29d in operator new[](unsigned int) () from /usr/lib/libstdc++.so.6
#7  0x080a9784 in vector_tpl<koord3d>::resize (this=0xee31e44, file=0xbfffcd2c)
    at dataobj/../tpl/vector_tpl.h:58
#8  route_t::rdwr (this=0xee31e44, file=0xbfffcd2c) at dataobj/route.cc:601
#9  0x081dcbf2 in convoi_t::rdwr (this=0xee31e38, file=0xbfffcd2c) at simconvoi.cc:2374
#10 0x081e098e in convoi_t (this=0xee31e38, wl=0xd0012b0, file=0xbfffcd2c) at simconvoi.cc:198
#11 0x08266727 in karte_t::laden (this=0xd0012b0, file=0xbfffcd2c) at simworld.cc:4595
#12 0x08268b08 in karte_t::laden (this=0xd0012b0, 
    filename=0xbc97298 "\300\243\264\v/sunderland-industrial-12.sve") at simworld.cc:4245
#13 0x0815e041 in savegame_frame_t::action_triggered (this=0xd597df0, komp=0xd598320, p=...)
    at gui/savegame_frame.cc:399
#14 0x080f8c29 in gui_action_creator_t::call_listeners (this=0xd598310, ev=0xbfffd280)
    at gui/components/../../ifc/gui_action_creator.h:36
#15 gui_table_t::infowin_event (this=0xd598310, ev=0xbfffd280) at gui/components/gui_table.cc:146
#16 0x080f6605 in gui_scrollpane_t::infowin_event(event_t const*) ()
#17 0x08128bc5 in gui_container_t::infowin_event (this=0xd597df4, ev=0xbfffd340) at gui/gui_container.cc:93
#18 0x08129d79 in gui_frame_t::infowin_event (this=0xd597df0, ev=0xbfffd3c4) at gui/gui_frame.cc:89
#19 0x0824694b in check_pos_win (ev=0xbfffd4a0) at simwin.cc:938
#20 0x0826b008 in karte_t::interactive (this=0xd0012b0, quit_month=2147483647) at simworld.cc:5563
#21 0x08218147 in simu_main (argc=1, argv=0xbffff434) at simmain.cc:1068
#22 0x082a5a6a in main (argc=1, argv=0xbffff434) at simsys_s.cc:743

This could just be saved game corruption, so it may be solved already.

Re: Exciting new crash.

Reply #1 –
Is this from 7.3 or -devel?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Re: Exciting new crash.

Reply #3 –
Hmm, this is an odd one, as it is idiosyncratic. The problem with an error in sim_new_handler() is that it is very difficult to work out what is going wrong: that is the method that allocates new memory for any object that uses the built-in memory pool (from Standard). In theory, it should only go wrong if the system runs out of memory, so what is happening in these cases is not clear to me. I have had the problem occasionally, too, but found no useful backtrace.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Re: Exciting new crash.

Reply #4 –
Quote from: jamespetts – on
Hmm, this is an odd one, as it is idiosyncratic. The problem with an error in sim_new_handler() is that it is very difficult to work out what is going wrong: that is the method that allocates new memory for any object that uses the built-in memory pool (from Standard). In theory, it should only go wrong if the system runs out of memory, so what is happening in these cases is not clear to me. I have had the problem occasionally, too, but found no useful backtrace.

My first thought was that I was running out of memory, but I checked and there was plenty of memory when simutrans wasn't running.  This indicates a *memory leak* to me -- most simple case, an infinite loop which keeps calling 'new'.  I'm not good at debugging memory leaks.

Re: Exciting new crash.

Reply #5 –
Hmm - I'm not sure about that. It really doesn't sound like a memory leak to me, or else your system would have run out of memory - and a sudden, fast memory leak on starting a map that engulfs the whole system's memory? That doesn't make a great deal of sense to me...
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Re: Exciting new crash.

Reply #6 –
Quote from: jamespetts – on
Hmm - I'm not sure about that. It really doesn't sound like a memory leak to me, or else your system would have run out of memory - and a sudden, fast memory leak on starting a map that engulfs the whole system's memory? That doesn't make a great deal of sense to me...

Yeah, but what else crashes 'new'?  There are lots of ways to crash 'delete', but 'new'?

(Brainstorms) Bad argument to new[]?  Perhaps -1 or something?

Re: Exciting new crash.

Reply #7 –
Or, conceivably, a bug in an over-ridden new[] operator somewhere - I know that the new[] operator is over-ridden in places in the Standard code.

Edit: Do you notice increased memory consumption immediately prior to the crash, incidentally...?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Re: Exciting new crash.

Reply #8 –
REading a route with zero entries may cause allocation of a route with 2^32-1 entires ...

Re: Exciting new crash.

Reply #9 –
Quote from: jamespetts – on
Or, conceivably, a bug in an over-ridden new[] operator somewhere - I know that the new[] operator is over-ridden in places in the Standard code.

Edit: Do you notice increased memory consumption immediately prior to the crash, incidentally...?

Hard to tell, but I thought so.  (EDIT: unfortunately I failed to keep track of which save game was causing it.)

Quote from: prissi
REading a route with zero entries may cause allocation of a route with 2^32-1 entires ...
Something like that could do it!

Re: Exciting new crash.

Reply #10 –
Quote from: prissi – on
REading a route with zero entries may cause allocation of a route with 2^32-1 entires ...

Could a check be implemented in route_t to guard against the possibility of attempting to read a route with zero entries?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.
 

Re: Exciting new crash.

Reply #11 –
Usually in standard an empty route has two entires ... but even then it should not fail and I never had such bug reports. I was just speculating, because there was one time a patch to make an empty route only one tile, and save games were converted during loading. If now in an older version there was zero, it may cause such an error.

But the savegame may be as well corrupted (or worngly saved), which is far more likely to me.

Code: [Select]
void route_t::rdwr(loadsave_t *file)
{
	xml_tag_t r( file, "route_t" );
	sint32 max_n = route.get_count()-1;

	file->rdwr_long(max_n, "\n");
	if(file->is_loading()) {
		koord3d k;
		route.clear();
		route.resize(max_n+2);
		for(sint32 i=0;  i<=max_n;  i++ ) {
			k.rdwr(file);
			route.append(k);
		}
	}
	else {
		// writing
		for(sint32 i=0; i<=max_n; i++) {
			route[i].rdwr(file);
		}
	}
}

This of course will fail for max_n<-2. But then the game must be corrupted earlier, since during writing route.get_count()-1 is written, which is always >= -1.