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