Comment 51 for bug 745836

Lets reiterate the current status:
- This only happens on an machine under heavy load with data on ecryptfs
- the stacktrace show:
  a) this to happen at various locations (the stacktraces are different).
  b) even more important: some of the stacktraces show things, that cant possibly be, if the underlying system works correct.
See the linked upstream discussion of this between me and Caolán McNamara.
Quote:
"The bug report's stack is from svx autocorrect, which means that ucbhelper::cancelCommandExecution and cppu::throwException have successfully thrown exceptions at least a hundred times or so before the crash, so its not the case that it's e.g. the first throw or two through the uno bridge."
this means that the following:
"With an eip of 0x100000 (in the i386 bug reports) meaning the call goes into nirvana."
cant really happen unless there is some serious memory corruption around (or the stacktraces themselves are wrong, however in general, they look sane). The eip == 0x100000 is in a lot of stacktraces here while it should be a random (and different) number (pointing to the created ExceptionThrower object) instead.

As of now, there is _no_ indication that Libreoffice itself is at fault. it might demonstrate the problem more clearly, because:
a) it is such a big project.
b) such crashers appear to be random noise in other projects.

@penalvch: I am not very happy about the setting of the bug state to confirmed again without discussion. My change was quite intentional given the above evidence. At least it needs to be set back to "Incomplete" until something shows Libreoffice to be at fault in this IMHO. To prevent a bug-state-war I will ask bugcontrol to have a look at it and leave state as is for now.