Do not move nCurUndoAction < 0

PROBLEM DESCRIPTION:
LibO crashes when accepting a change tracked change after having increased the number of undo steps and being at the end of the previously configured undo stack

STEPS TO REPRODUCE (not yet "optimized" - maybe there's a shorter path):
1. create a new, empty writer document, write some lines with arbitrary text.
2. open the preferences dialog, go to the memory (german „arbeitsspeicher“) part and set the number of undo-steps to five.
3. save the document somewhere and close the document
4. re-open the document
5. enable change tracking („änderungen aufzeichnen“ in German)
6. make six arbitrary, isolated changes to the document (change tracking should mark the changes)
7. click „undo“ as often as possible (should be five) and do not do anything else after that (don't even move the cursor – I'm not sure if that matters but that was my way to reproduce)
8. open the preferences dialog, go the memory part and increase the number of undo steps to ten.
9. right-click on any of the remaining changes with markup from change tracking and choose „accept change“ („Änderung akzeptieren“ in German)
10. -> Immediate Crash of LibreOffice

CURRENT BEHAVIOR:
crash (document is recoverable)

EXPECTED BEHAVIOR:
 - no crash
 - change is accepted
 - accepting the change can be undone

Platform (if different from the browser):

Browser: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2

Windows Vista Business 64bit, Kaspersky AV

UPDATE:
It's not even necessary to change the depth of the undo stack - The crash can be provoked by simply setting the undo depth to 5, restarting LibO, making six change tracked changes and accepting one of the via the context menu.

Created attachment 65345
Bug 47283 - WinDbg session

Confirmed with:
LO 3.5.5.3
Build ID: own W7 debug build
Windows 7 Professional SP1 64 bit

Attached full WinDbg session with mini dump file loaded generated by procdump soffice.bin -h.

NEW as bug confirmed and bt attached.

Raising importance to CRITICAL as a crash results in loss of data.

Can this bug be better described as "crash when loading document with more changetracking steps than the current Undo depth"?
I assume that that is what is happening here. If so, the most simple solution (to prevent data loss) is to not load such a document.

Do you know how many changetracking steps there are before opening a document? Also, when it crashes, do all instances of LibreOffice crash (if you have multiple documents open)? If the answers are NO/YES then you could accidentally open the document and lose data across multiple documents.

@All: I was NOT able to reproduce the bug in LibO 3.6.1
      Strictly spoken one should find out the reason for the crash nevertheless so someone can write a regression test.

@Björn & Joel: see my "Comment 1" - I found out later on that opening / closing LibO has nothing to do with the issue.

@Björn, I'd like to learn how to write a regression test, if you take this one, you mind if I tag along and learn while you do it?

can reproduce the same stack as the attachment, with the following STL assertion:

/usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/debug/safe_iterator.h:359:
    error: attempt to advance a dereferenceable (start-of-sequence)
    iterator -1 steps, which falls outside its valid range.

but only in 3.5, not in OOo 3.3 or LO 3.6/master.

this is a regression in Writer with the undo refactoring from OOo 3.4.

change tracking is not necessary to reproduce it, the problem is in the undo stack; but with many actions it does not crash for me, i found that inserting a table does make it crash.

this was fixed by this commit from Stephan:
db59e4481614f58e111a86a1926e49fb523ebbae

since afaik there won't be another release after 3.5.7 i don't
think there is anything to do here.

Thanks for chasing that down Michael ! - if there is no release after 3.5.7 - then no harm in cherry-picking it, as I've just done :-) I suspect we may get some security bug related release at some stage there.