Bug 42543 - Report Designer Wizard missing Label display and editing capability
Summary: Report Designer Wizard missing Label display and editing capability
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
3.5.0 RC1
Hardware: x86-64 (AMD64) Linux (All)
: high blocker
Assignee: Caolán McNamara
URL:
Whiteboard: target:3.5.0.3 target:3.6.0beta0 targ...
Keywords: regression
: 45258 (view as bug list)
Depends on:
Blocks: mab3.5
  Show dependency treegraph
 
Reported: 2011-11-03 01:29 UTC by Alex Thurgood
Modified: 2013-01-20 20:10 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot of missing display (17.72 KB, image/png)
2011-11-03 01:29 UTC, Alex Thurgood
Details
label display ok (30.92 KB, image/png)
2011-11-26 05:04 UTC, Julien Nabet
Details
First bt with attached symbol (5.48 KB, text/plain)
2012-01-26 13:25 UTC, Julien Nabet
Details
Second bt (4.60 KB, text/plain)
2012-01-26 13:26 UTC, Julien Nabet
Details
4 first bt of solar mutex (6.22 KB, application/zip)
2012-01-31 12:18 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Thurgood 2011-11-03 01:29:21 UTC
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
Comment 1 Julien Nabet 2011-11-26 05:04:31 UTC
Created attachment 53863 [details]
label display ok

On 3.4.4 Debian testing pc x86-32, it's ok.
Comment 2 Julien Nabet 2011-11-26 05:05:17 UTC
Alex: could you please confirm if it's ok for you too ? (I don't have x64 to test)
Comment 3 Alex Thurgood 2011-11-26 05:26:10 UTC
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
Comment 4 Julien Nabet 2011-11-26 05:51:46 UTC
Alex: you're absolutely right, I reproduce it too with master :-(
Comment 5 Lionel Elie Mamane 2011-11-28 02:16:28 UTC
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.
Comment 6 Alex Thurgood 2011-11-28 02:28:40 UTC
(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
Comment 7 Caolán McNamara 2012-01-23 06:32:47 UTC
is this still busted ?
Comment 8 Lionel Elie Mamane 2012-01-23 07:27:20 UTC
I reconfirm the bug on current libreoffice-3-5.
Comment 9 Alex Thurgood 2012-01-23 07:54:11 UTC
Need to test on my Linux box.

Alex
Comment 10 Alex Thurgood 2012-01-26 00:24:53 UTC
*** Bug 45258 has been marked as a duplicate of this bug. ***
Comment 11 Alex Thurgood 2012-01-26 00:26:02 UTC
(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
Comment 12 Alex Thurgood 2012-01-26 01:40:17 UTC
Setting as blocker for 3.5 release.
Comment 13 Julien Nabet 2012-01-26 13:25:19 UTC
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)
Comment 14 Julien Nabet 2012-01-26 13:26:21 UTC
Created attachment 56206 [details]
Second bt

Following the first bt, i continued gdb and had a second bt.
Comment 15 Lionel Elie Mamane 2012-01-26 21:19:50 UTC
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!
Comment 16 Julien Nabet 2012-01-29 02:54:58 UTC
(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.
Comment 17 Lionel Elie Mamane 2012-01-29 08:08:22 UTC
(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".
Comment 18 Lionel Elie Mamane 2012-01-29 08:19:35 UTC
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.
Comment 19 Julien Nabet 2012-01-29 09:53:19 UTC
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 :-(
Comment 20 Lionel Elie Mamane 2012-01-30 08:37:28 UTC
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.
Comment 21 Lionel Elie Mamane 2012-01-30 10:14:18 UTC
(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.
Comment 22 Lionel Elie Mamane 2012-01-30 14:40:27 UTC
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.
Comment 23 Lionel Elie Mamane 2012-01-30 14:43:35 UTC
(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.
Comment 24 Jan Holesovsky 2012-01-31 08:19:11 UTC
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?
Comment 25 Julien Nabet 2012-01-31 12:18:50 UTC
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
Comment 26 Michael Stahl (allotropia) 2012-02-03 07:31:58 UTC
fixed in libreoffice-3-5:
 d26f06b33b6958cb15b16dbfe3e12ab0126c23a7

fixed in libreoffice-3-5-0:
 b6c00fb358cbfcd74d71e99a8fe3b277a1f87a32
Comment 27 Not Assigned 2013-01-20 20:10:21 UTC
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.