Created attachment 71592 [details] bt + console logs on master Problem description: On pc Debian x86-64 with master sources updated today (commit 3bbe79eef841ae4a756593557641e32fa28c0184), I had a crash when trying to open the report included in file attached of fdo#48056 Steps to reproduce: 1. Open Lo Base 2. Retrieve file https://bugs.freedesktop.org/attachment.cgi?id=59233 3. Try open the report "Bericht1" Current behavior: Crash Expected behavior: No crash and open the report Operating System: Debian
Created attachment 71593 [details] bt + console logs on 3.6 With 3.6 sources (commit 6e963da804ed6f222a4a6c5f373d7ea6532d75ad), I reproduced this too.
With 3.5.4.2, I don't have the crash and reproduce what's described in fdo#48056
We (Joel Madero) and I can reproduce this using the latest 4.1 version; NO CRASH, but an error message, and we can't open the report. (see attachment) Tested with: Ubuntu 12.10, LO build today (Version 4.1.0.0.alpha0+ (Build ID: 92afb61d8bb1b264a945371065115981ecaed0f)) (Joel Madero tested it with Bondhi).
Created attachment 72748 [details] Error message Ubuntu 12.10 LO 4.1 latest master
(In reply to comment #4) > Created attachment 72748 [details] > Error message Ubuntu 12.10 LO 4.1 latest master When I had a look at the screenshot I have seen "Report_Diagramm.odb". Its this attachment https://bugs.freedesktop.org/attachment.cgi?id=59233 ... and the report of this attachment already says: Report with charts fails ... see: https://bugs.freedesktop.org/show_bug.cgi?id=48056 The error-message you reported is different to the message of other versions since 3.5.0, which couldn't open such a report. But it could be the same reason, if you don't test it with a report, which doesn't contain a chart.
Yep, same here on Linux Mint 13 32 bit, with : Version 4.1.0.0.alpha0+ (Build ID: 6880e2d31a38d5f4b44ba4f5b4a2b3e361a6631) Alex
What I meant is that it doesn't crash, but I get the same error message as Joren. Alex
DUP of #48056 ?
(In reply to comment #8) > DUP of #48056 ? No, crash is most probably different problem than the "failed to parse".
So, here's what is happening: The reportdesign::OShape claims to have properties "CustomShapeEngine", "CustomShapeDesign", etc, but when one tries to get their value, the internal m_aProps.aComponent.m_xProperty throws com::sun::star::beans::UnknownPropertyException which is unexpected and thus aborts LibreOffice. The internal m_aProps.aComponent.m_xProperty seems to be completely empty (!), while the hasPropertyByname method recognises more than 200 property names! Possibly this is a problem of query aggregation (the "get property value" is dispatched to the wrong object), but I think this is rather that the OShape is not initialised properly. This could after all have the same underlying reason as bug 48056. Any further than that, I'm stumped.
Created attachment 78432 [details] paper over the problem patch Here's a patch that papers over the abort problem, but does not solve the "real" underlying problem. Note that even with this patch, the chart does not actually work :-|
Lionel: I haven't tested your workaround patch but I entirely trust you (since you're the Base expert) and suppose it works :-). I think that at least there's no more crash with it so it could be interesting to push it on master. Obviously you can let a comment in the commit + FIXME in the code. Sometimes the mess can't be fixed in one time :-) What do you think?
So, the crash had the same origin as bug 48056 after all, but happened only in dbgutil builds, because of the extra checking contained therein (the program was aborting on an inconsistency). Since this "crash" is non-reproducible now, I'm leaving it as a canary so that dbgutil builds "fail early fail hard" if a similar problem comes in future.
Created attachment 78830 [details] console + bt with symbols on master sources On pc Debian x86-64 with master sources updated today, I still reproduce the problem. The bt attached is different from others (that's why I put the other to obsolete)
Lionel: canary is still dead here :-( Here's my autogen.input: --with-system-odbc --enable-ext-barcode --enable-ext-diagram --enable-ext-google-docs --enable-ext-hunart --enable-ext-nlpsolver --enable-ext-ct2n --enable-ext-numbertext --enable-postgresql-sdbc --enable-ext-presenter-minimizer --enable-ext-typo --enable-ext-validator --enable-ext-watch-window --enable-ext-wiki-publisher --enable-dbus --enable-graphite --enable-evolution2 --enable-werror --enable-debug --enable-dbgutil --enable-crashdump --enable-dependency-tracking --enable-online-update --enable-ext-mariadb-connector --enable-extra-sample --enable-extra-template --enable-extra-gallery
(In reply to comment #14) > On pc Debian x86-64 with master sources updated today, I still reproduce the > problem. What git commit id?
git log -1 gives this: commit 630bc850f7e36f75d295fc1d4a3cc56acd6921e7 Author: Kohei Yoshida <kohei.yoshida@gmail.com> Date: Fri May 3 21:37:38 2013 -0400 Additional unit test for sorting. Change-Id: Ic7834a07341cee2b2fdcff3ae0707755e5500347
Just for information, I did a "make clean && make dev-install" (I haven't done it since some days). I reproduce the crash.
(In reply to comment #14) > On pc Debian x86-64 with master sources updated today, I still reproduce the > problem. > The bt attached is different from others (that's why I put the other to > obsolete) This is a completely different crash, with a different backtrace and a different reason / source. I've opened bug 64279 for it. Closing this one again.
(In reply to comment #3) > We (Joel Madero) and I can reproduce this using the latest 4.1 version; > NO CRASH, but an error message, and we can't open the report. (see > attachment) This means that you have *NOT* reproduced this bug, but found *another* one (which has different cause, different dates of appearance, etc).
Thank you Lionel for the explanation! I'm reading right now the bugtracker you created.