Created attachment 53096 [details] screenshot of missing display How to reproduce : 1) Open a ODB file. 2) Click on the Report icon. 3) Start the Report Creation Wizard 4) In Step 2, note how the Field Label display and editing capabilities are not displayed - see attached screenshot. What should happen : User should see and be able to edit the labels of the fields for the report. Confirmed by Julien Nabet. Alex
Created attachment 53863 [details] label display ok On 3.4.4 Debian testing pc x86-32, it's ok.
Alex: could you please confirm if it's ok for you too ? (I don't have x64 to test)
Hi Julien, I raised the bug against Master, not the 3.4.X series, so this is a regression with respect to that series and 3.3.x. Alex
Alex: you're absolutely right, I reproduce it too with master :-(
I get a boatload (about 1580 repetitions) of: warn:legacy.osl:10068:1:/home/master/src/libreoffice/core/vcl/source/app/dbggui.cxx:1976: SolarMutex not locked May or may not be linked.
(In reply to comment #5) > I get a boatload (about 1580 repetitions) of: > > warn:legacy.osl:10068:1:/home/master/src/libreoffice/core/vcl/source/app/dbggui.cxx:1976: > SolarMutex not locked > > May or may not be linked. Michael Meeks' GTK3 stuff in your debug build ? Alex
is this still busted ?
I reconfirm the bug on current libreoffice-3-5.
Need to test on my Linux box. Alex
*** Bug 45258 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > is this still busted ? Both Lionel and Drew have also confirmed that this still occurs (even in RC2 for Drew). Alex
Setting as blocker for 3.5 release.
Created attachment 56205 [details] First bt with attached symbol Here is the steps I did : - Open Base with a file - Call Wizard for Report - select fields in first step - attach gdb (see http://wiki.documentfoundation.org/Development/How_to_debug#Attaching_to_the_soffice.bin_process) - since I didn't know where was the pb I runned : - catch catch (to stop gdb when "catch" called) - catch thrown (to stop gdb when "throw" called) - I had to run a lots of time "continue" (or "C") because of all the "catch" and "throw" - then I clicked on "Next" -> first bt (Pc Debian x86-64)
Created attachment 56206 [details] Second bt Following the first bt, i continued gdb and had a second bt.
The first bt (attachment 56205 [details]) is interesting: dbtools::throwGenericSQLException (_rMsg="There exists no query named \"Adresse\"." ...) Some code tries to use a query named: "Adresse". insted of just: "Adresse" So we have to hunt where that extra dot comes from and hopefully this will solve this bug!
(In reply to comment #15) > The first bt (attachment 56205 [details]) is interesting: > > dbtools::throwGenericSQLException (_rMsg="There exists no query named > \"Adresse\"." ...) > > > Some code tries to use a query named: > "Adresse". > insted of just: > "Adresse" > > So we have to hunt where that extra dot comes from and hopefully this will > solve this bug! I put a breakpoint on RowSet just before the message : (gdb) b RowSet.cxx:2382 Breakpoint 1 at 0x7f7c39cc31d5: file /home/julien/compile-libreoffice/libo/dbaccess/source/core/api/RowSet.cxx, line 2382. (gdb) c ... Breakpoint 1, dbaccess::ORowSet::impl_buildActiveCommand_throw (this=0x353d360) at /home/julien/compile-libreoffice/libo/dbaccess/source/core/api/RowSet.cxx:2382 2382 sMessage.SearchAndReplaceAscii( "$table$", m_aCommand ); (gdb) print m_aCommand $1 = "Adresse" (gdb) n 2383 throwGenericSQLException(sMessage,*this); (gdb) print sMessage $2 = "There exists no query named \"Adresse\"." So m_aCommand seems ok, it's just the message which shows this "." in extra. BTW : I got a log of segmentation faults where trying to gdb the report part.
(In reply to comment #16) > So m_aCommand seems ok, it's just the message which shows this "." in extra. Ah yes, I confused the dot "namespace separator in SQL" and the dot "end of sentence in English".
OK, the code path that leads to the SQL exception is: switch (m_nCommandType) { case CommandType::TABLE: { (...) } break; case CommandType::QUERY: { Reference< XQueriesSupplier > xQueriesAccess(m_xActiveConnection, UNO_QUERY); if (xQueriesAccess.is()) { if (xQueries->hasByName(m_aCommand)) { (...) } else { String sMessage( DBACORE_RESSTRING( RID_STR_QUERY_DOES_NOT_EXIST ) ); sMessage.SearchAndReplaceAscii( "$table$", m_aCommand ); throwGenericSQLException(sMessage,*this); } } } My guess is that in the example you test on, "Adresse" is a table and not a query, so m_nCommandType should be CommandType::TABLE, but it is CommandType::QUERY. So now the interesting question is: where is that value of m_nCommandType set, and why is it set incorrectly? Probably somewhere a call to setPropertyValue(PROPERTY_COMMAND_TYPE). This also suggests that it might work if one selects a query, and not a table in step 1 of the query wizard. To be tested.
I noticed the pb with CommandType::TABLE. So in gdb, I changed dynamically the value. Then I had "select * from Adresse" (something like that) and this time it has CommandType::TABLE (so 0) instead of 1 CommandType::QUERY. (Hope I don't mistake, I didn't record it somewhere) So I changed this too dynamically on gdb but the result wasn't better :-(
I don't get the CommandType::TABLE vs CommandType::QUERY problem, so probably that's an orthogonal problem. In the case CommandType::TABLE, we have: if ( bDoEscapeProcessing ) { Reference< XNameAccess > xTables( impl_getTables_throw() ); if ( xTables->hasByName(m_aCommand) ) { } else This empty block there is very suspicious. It contained stuff, which was commented out in commit d4d5d883ecbc6e04cd28bb49be4c85f560a1bc48 Author: Ocke Janssen [oj] <Ocke.Janssen@sun.com> Commit: Noel Power <noel.power@novell.com> Date: Fri Jan 22 08:14:22 2010 +0100 dba33f: #i108548# extend SingleSelectQueryComposer appendFilterByColumn with additonal parameter The commented out code itself was removed in commit 910a1f688b21fb8104f756b108b90836840f70db Author: Rubén Jáñez <rjanezfer@gmail.com> Commit: Ocke Janssen [oj] <Ocke.Janssen@sun.com> Date: Mon Oct 11 10:39:25 2010 +0100 Removes some bogus comments found in Base. My hunch is that we just have to add that code again. Testing that now.
(In reply to comment #20) > My hunch is that we just have to add that code again. Testing that now. No, that does not solve the problem :-( I get a boatload of warn:legacy.osl:10241:1:/home/master/src/libreoffice/core/vcl/source/app/dbggui.cxx:1976: SolarMutex not locked Don't know if its is linked.
Caolán, could you please take a look at this? The "SolarMutex not locked" warnings make me think of a "VCL used/called in an incorrect way" problem, and you are the "friendly VCL expert". I added more or less random "SolarMutexGuard g" to the code until no warning, but that did not solve the problem... If the SolarMutex warnings are not related, maybe you can tell me which DB-related code returns a bad / wrong / empty value or throws what exception that makes that bit fail? I get rather lost between the Java code and the C++ UI code. Note that I cannot reproduce Julien's exceptions / backtraces, so there is at least one additional problem to the one unearthed by Julien, which still leads to this bug for me.
(In reply to comment #19) > I noticed the pb with CommandType::TABLE. > So in gdb, I changed dynamically the value. > Then I had "select * from Adresse" (something like that) and this time it has > CommandType::TABLE (so 0) instead of 1 CommandType::QUERY. For what it is worth, if m_aCommand is "SELECT * FROM Adresse", then m_nCommandType should be CommandType::COMMAND, not ::QUERY, nor ::TABLE.
Fixed in master: http://cgit.freedesktop.org/libreoffice/core/commit/?id=03e17a141fbb4e1242de9d9979b5b699e6840454 Big thanks to Lubos who found the vcl commit that changes the behavior of painting of windows when they overlap. I'm just about to ask for reviews on the ML - Lionel, can you check, please?
Created attachment 56407 [details] 4 first bt of solar mutex I added the 4 first bt I had about Solar mutex. BTW : i'm glad this bug is resolved of course but I wonder how it can work with the pb of CommandType::COMMAND and CommandType::TABLE
fixed in libreoffice-3-5: d26f06b33b6958cb15b16dbfe3e12ab0126c23a7 fixed in libreoffice-3-5-0: b6c00fb358cbfcd74d71e99a8fe3b277a1f87a32
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7f038472fb4640f01f028185dc5e19781e8a8459 pyagenda: Fix fdo#42543 in python The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.