When going to the first chamber below it crash. I don't know why it happened.

Here the printed message.

print_trace:  Obtained 7 stack frames.
print_trace:  Obtaining symbols now done.
freedroidRPG(print_trace+0x1e) [0x809407e]
[0x9e4400]
freedroidRPG(DoAllMovementAndAnimations+0x10) [0x809e330]
freedroidRPG(Game+0x65) [0x809e3b5]
freedroidRPG(main+0x149) [0x809e569]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x14be37]
freedroidRPG() [0x805ccb1]

print_trace():  received SIGSEGV!

Thanks for taking time to report this bug.

Could you attach a backtrace, please ?

Ok, Thanks for the backtrace. :)

This is not a usable backtrace hakzsam and you should know that. 
The report also lacks a version number without which we'll do nothing.

Nabla - thanks for the report!
This issue makes the game crash so it's quite serious.

Can you please specify which version of the game you were using, and include
the complete output of the game when it starts? Please also mention your
platform (Windows, Linux, etc.).

If you can readily reproduce the problem, perhaps you could attach a savegame
that would enable us to do it. A backtrace from within GDB would be appreciated
if you know how to get one.

Thanks!
-- 
Greetings, 
A. Huillet

Indeed, I was wrong...

nabla, see this page http://www.freedroid.org/pmwiki/pmwiki.php/Main/BackTraces

Thanks in advance.

I play version 0.14.1.1 from playdeb.

How can i make a useable backtrace?

I compiled the release version that is in sourceforge (svn didn't want to
compile) because my version had no symbol.

I use Ubuntu 11.04 .
 The savegame is attached and the gdblog

Your savegame isn't complete. tux.shp is missing.

Fluzz, Joseph, can you tell me what you think could cause this crash? I know
I've seen this issue in the past.

By the way, a SIGSEGV is critical.

I was able to reproduce the crash with the attached savegame. I find out that
the crash was caused by negative obstacle type in the obstacle list. You can
check it easily by examining the savegame file.
Fluzz claimed it's the old bug. He said the obstacle list wasn't cleared before
loading a savegame.
I'm closing the issue.

Not exactly. It was about the list not being cleaned up before to save it, iirc. But yes it was fixed.

----- Reply message -----
De : "Józef Kucia - Roundup" <bugs@freedroid.org>
Date : lun., sept. 19, 2011 20:12
Objet : [issue454] SIGSEGV in access tunnel for shield control
Pour : <freedroid-bugs@lists.sourceforge.net>

Józef Kucia <joseph.kucia@gmail.com> added the comment:

I was able to reproduce the crash with the attached savegame. I find out that
the crash was caused by negative obstacle type in the obstacle list. You can
check it easily by examining the savegame file.
Fluzz claimed it's the old bug. He said the obstacle list wasn't cleared before
loading a savegame.
I'm closing the issue.

----------
status: open -> resolved

________________________________________
FreedroidRPG issues <bugs@freedroid.org>
<http://bugs.freedroid.org/b/issue454>
________________________________________

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Freedroid-bugs mailing list
Freedroid-bugs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedroid-bugs

Reopening following reports that this still happens in .15.

Recipe to reproduce the bug:
- 1) on a level with a least one neighbor, add a crate and a bloor door, in that
order (be sure that there are not on-going combats on the level, so that oil or
blood stains are not added *after* the door)  
- 2) destroy the crate
- 3) walk to the neighbor level, far away to be sure that the modified level is
no more visible. 
- 4) save 
- 5) walk back to the modified level 
- 6) save - KABOOM

Fixed in svn r5367.
Here is the commit log, that shortly explains the bug:
----------------------------------------------------------
Do not restrain dirty_animated_obstacle_lists() to visible levels only. 
This fixes a bug that leads to create and save obstacles with negative index in
a very specific case: 
defrag_obstacle_array() is called when a game is saved, and a destroyed object
can be replaced by an animated door. In that case, the type of the element that
was containing the door is set to -1. If the defragged level is a non-visible
neighbor of the current level, then it's animated obstacle list is not dirty and
so the door's old index (whose type is now -1) is used by animate_door() which
can decrement the value of the obstacle type.
----------------------------------------------------------

Also added a protection in animate_door() to avoid to decrement an obstacle if
it's type is not a door type, in svn r5368