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.
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)
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: 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:
> SolarMutex not locked
> May or may not be linked.
Michael Meeks' GTK3 stuff in your debug build ?
is this still busted ?
I reconfirm the bug on current libreoffice-3-5.
Need to test on my Linux box.
*** 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).
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]
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:
insted of just:
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:
> insted of just:
> 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.
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) 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:
Reference< XQueriesSupplier > xQueriesAccess(m_xActiveConnection, UNO_QUERY);
String sMessage( DBACORE_RESSTRING( RID_STR_QUERY_DOES_NOT_EXIST ) );
sMessage.SearchAndReplaceAscii( "$table$", m_aCommand );
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) )
This empty block there is very suspicious. It contained stuff, which was commented out in
Author: Ocke Janssen [oj] <Ocke.Janssen@sun.com>
Commit: Noel Power <email@example.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
Author: Rubén Jáñez <firstname.lastname@example.org>
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:
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:
fixed in libreoffice-3-5-0:
Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":
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:
Affected users are encouraged to test the fix and report feedback.