Follow-up Comment #19, bug #25037 (project gnustep):
I added a lot of NSLog statements to NSUndoManager.m and nsundomanager.m, but
I do not yet figured out what the problem is. appended is the NSLog output.
nsudndomanager is run from within gdb, the output is from on the sparc64.
The same done on i386, the only difference is that the setState immediately
after continuing the running program after the breakpoint, is set to 1 instead
to 0 on the sparc64 box.
either the problem is there in undoing the thing, or it happened before, when
putting the 1 on the undo stack. right now I have the feeling the undo would
work, if there would have been the right stuff on the undo stack before, at
least I can see, the setState gets called via the NSInvocation.m from the
NSUndoManager.m.
I did not figured out yet, where it actually stored the stuff for later undo
on that undo stack, and what it actually did put onto it.
Or, when I take a look at the backtrace, maybe a bug in libffi on sparc64?
(file #17226)
_______________________________________________________
Additional Item Attachment:
File name: nsundomanager.logoutput Size:5 KB
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?25037>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep
