Apache OpenOffice (AOO) Bugzilla – Issue 886
Crash while switching off design mode on forms
Last modified: 2003-12-06 14:52:32 UTC
Drop a button component into a writer doc. Switch off design mode. -> OO627 crashes.
TH->SBA: Couldn't reproduce this problem in the current version. Please take a look at this problem.
I could not reproduce it on Win2000 with my OO627 either. => Dietrich, please add a few more details.
OK, I have it. The crash happens with the new dlls I've built to fix a problem with JDBC: jdbc2.dll, sdbc2.dll, dbtools2.dll I replaced connectivity/source/drivers/jdbc/Jdriver.cxx tools.cxx object.cxx, source/inc/java/tools.hxx and source/inc/java/util/Property.hxx by the current versions from cvs. Then I "dmade" connectivity and replaced the original 3 dlls. I did this according to <A HREF="http://dba.openoffice.org/dba-dev/msg00108.html">dba-archive</A> -> crash
Dietrich, as I think that you have a debugger at hand: do you have a stack of the crash? And can you please add some more details about the data the document is working with? BTW: Perhaps we should re-assign this bug to dba instead of gsl. I know that the forms module (which may be involved here) is part of the gsl project, but this is to be changed, anyway (it clearly belongs into dba).
Er - a machine stack? Hexadecimal/ASCII? Maybe I should send you the three dlls? No data, I drop a button and switch off design mode, that's all. If you want to reassign this bug, go ahead.
NO DATA? This means you simply drop a button in the doc, switch off the design mode and then it crashes? Without specifying a data source for the form? And this happens only if your new libs are used? If so, this sounds like an incompatibility of your libs. Besides the fact that I'm not sure if they should be used at this moment (which seems to be a bug of it's own), would you please try to rebuild your libs? For the stack: * start the office from within the developer studio (or attach to a running process viao Build/Start Debug/Attach to process - if you have version 6) * if the office crashes, the debugger should show you at least the library where this happened (View/Debug Windows/Call stack or Alt-7) * link this libraries in question with debug enabled (only link, no new compilation needed), place it in your office program dir * now if OOo crashes, you should see a list of method names, which is the stack frame You could extend this with every other library on the stack (link it with debug), but mostly the 1 or maybe 2 libs are enough so that the stack is somewhat meaningful. But if this is really an incompatibility, the stack is usually useless, so could you please try this (incompatibility theory) first?
Reassigned to Frank
>This means you simply drop a button in the doc, switch off the design mode >and then it crashes? Without specifying a data source for the form? >And this happens only if your new libs are used? Yes, yes and yes. Run from within VCC, I first get unhandled exception in soffice.exe: cppuhelper2msc.dll 0xC0000005: Access Violation. After clicking OK, the call stack (Alt F7) contains: cppuhelper2msc! dl627mi! Is it possible that I have to exchange dba627mi.dll or something? I've rebuilt normally and run in the debugger, then with debug=1 and run in the debugger.
> Run from within VCC, I first get unhandled exception in > soffice.exe: > cppuhelper2msc.dll 0xC0000005: Access Violation. > After clicking OK, the call stack (Alt F7) contains: > cppuhelper2msc! > dl627mi! This is an incompatibility. Though I can't imagine why ... It looks as if the dl lib (which is built in graphics/svx and contains the code from svx/source/form and svx/source/fmcomp) is incompatible. Of the 3 libs you exchanged, the only one which the dl*.dll links against is dbtools, so I assume that this causes the trouble. (BTW: didn't notice this earlier, but: Why did you exchange _3_ libs? From the files you modified I would assume that only jdbc2.dll should have been affected ...) Solution 1 would be to get the svx module and recompile the 2 mentioned directories, but this would only fix symptoms (and may not be sufficient). What if you just us your jdbc2.dll, and leave the others untouched? Is it possible that you did more changes in connectivity than only the files mentioned? Would you mind trying a new (clean) approach and get a new connectivity project, compile it (_without_ doing the java changes for now), use it's libs, and see if it still crashes? If _not_, patch the java files and use the new java lib (the other's shouldn't have changed now!). This would help tracking down the problem (it may even be that the code in connectivity as got from OOo for SRC627 is not really compatible with the 627 version. Wouldn't be the first bug of this kind ...)
A new test with jdbc2.dll only no longer crashes. There must be an incompatibility between dbtools/sdbc and the rest of the office, or VCC Standard compiles so differently from VCC optimizing, that an incompatibility occurs. Besides it was necessary to use JDK1.2.2, not JRE1.2.2 with OOo. The standalone JRE seems not to work. D.
Dietrich, do you (as the submitter) object against closing this bug? It obviously does not happen in the latest build anymore, and it was an incompatibility of your build only ....
forgot to mark this as "verified" ...
closing this - verified it, and got no feedback from Dietrich.