Use case : A user on the French list has the enclosed ODB for which reports have been created. The user noticed that on his Windows system, the report opened correctly with separator lines between the returned value in OOo 3.2.1, but with LibO the separators lines were not visible. Whilst attempting to reproduce the buggy behaviour, I opened the file on Mac and tried to open the report. A window was intialised, and then the process hung or entered a race condition, from which the only possible recovery was a process kill. The report to be tested is : "Liste Films V2" I am also enclosing stack / thread trace. Alex
Can't attach file because it exceeds file size limit for attachments. A link to file underneath : http://cjoint.com/?0cen6RPbnhB Alex
Created attachment 42931 [details] Trace of hung process
I can also confirm that the separator lines are displayed on OOo 3.2.1, OOo 3.3.0 (which does not hang) and NeoOffice 3.1.2, so the display behaviour is a regression. The hang / race condition appears to be specific to Mac. Alex
Linking to 33617 as I think that the drawing of lines in the report is the initial problem that causes LibO to hang on Mac. Alex
Created attachment 43472 [details] trace when attempting to open report from test db
Hi all, Am enclosing another trace, because the problem is still present in 3.3.1 RC1. This makes the report module completely useless for me on Mac OSX. Will also enclose test db. Alex
raising importance
Created attachment 43473 [details] Test db that causes problem
Comment on attachment 43473 [details] Test db that causes problem This is not the same db as in the original test, but the effects are the same
This is a regression compared to OOo 3.2.1 and OOo 3.3, in which the report can be opened and displayed correctly. Alex
Adding as nominee to 3.3.2 blocker. Reports are unopenable on Mac.
I should've have written reports _of this kind_ are unopenable on Mac.
LO installs the Report Builder extension by default in compare with OOo. I have seen other similar problems with that extensions in the past. Alex, does it help you to uninstall the extension?
@Petr : If I uninstall the Report Builder, how will I open the report ? Additionally, the only apparent way to do this on Mac is to forcibly delete the SRB folder from the extensions uno_cache directory because it is part of the bundled extensions and unopkg won't do it for me (I have tried). The only options available for the bundled extensions using unopkg are "list", "validate" and "reinstall". Alex
@Petr : so I forcibly deleted the folder containing the SRB. Restarted LibO. Tried to open report from test.db. LibO complained that I need the SRB - no surprise there. Downloaded SRB from Oracle Extension site, installed for all users. Closed LibO, restarted and tried again. LibO hangs. Force kill, ignore trace report, restart, ignore recovery, try again, hang. Systematically reproducible hang. Spinning beachball mania, as the Mac people would put it :-/ Alex
OOo/LO has an easier report engine even without the "Report Builder" extension. I though that it might be enough to see the report. OK, it wasn't. I have reproduced the problem with the missing line breaks on Linux. OK, we have two separate problems here: 1. Report builder extensions freezes on MAC. Alex, does it freeze only with this particular report or is it completely unusable? 2. It does not show the line separator on Linux and Windows. Alex, could you please open separate bug for this? Note that it is always confusing to solve more problems in one bug. In addition, the first problem will be solved by a MAC expert. The second problem will be solved by a Base expert.
@Petr Hi I did originally link this to Issue 33617. Shall I do so again ? Alex
@Petr: I can open all of the reports from the films.odb database in OOo 3.3.0. I can not open any of the reports from the same file in LibO 3.3.1 - each attempt causes LibO to hang. Alex
Forgot to add that some of the reports do not contain any spacer lines whatsoever, so the problem is a general one of not being able to open reports at all on Mac OSX. Alex
(In reply to comment #17) > Hi I did originally link this to Issue 33617. Shall I do so again ? Please, do not do it. They do not depend on each other and it would just add confusion. Well, it would be great if you could attach the sample file to the bug #33617 as well. Also a screenshot showing the difference could help the developer to understand and fix the problem faster.
(In reply to comment #19) > Forgot to add that some of the reports do not contain any spacer lines > whatsoever, so the problem is a general one of not being able to open reports > at all on Mac OSX. Let's keep this bug just for this problem. Thorsten, could you please have a look at it? Note that it is currently nominated as 3.3.2 blocker. Well, we should not block the release for other architectures because of this. We should fix if possible but I am not sure how many MAC users actually use this feature.
Errm, all of those Mac users who use the database functionality, or are likely to receive an ODB file from someone else ? Alex
In other words, people that are trying to use LibO in a business context on a Mac. Probably quite a few, although perhaps admittedly not as many as just use the spreadsheet or wordprocessor. Otherwise, the solution for me is simple, I go back to OOo, at least it works there and that is a good enough reason in a business use case not to recommend using LibO in a multiplatform environment. Alex
(In reply to comment #20) > > Please, do not do it. They do not depend on each other and it would just add > confusion. Well, it would be great if you could attach the sample file to the > bug #33617 as well. Also a screenshot showing the difference could help the > developer to understand and fix the problem faster. Ok will sort that out and post screenshots on bug 33617. Alex
The original file at http://cjoint.com/?0cen6RPbnhB just gives me a random error msgs in French - Alex, could you mail the file, or put it somewhere else?
Really looks like a deadlock to me. Let me see whether I can reproduce it.
Oh, Alex, regarding blocker-or-not - sorry, this went under our radar - if we have a fix ready for 3.3.2, we take it, but if not - why delay that release with many useful fixes for all platforms? 3.3.3 is just one month later - and it's no regression for 3.3.1 specifically.
@Thorsten : just take the second testdb that I've already attached here, it produces the same behaviour and is much smaller. The original French ODB file was attached to Ci-joint, but it has obviously expired from there, and it was too big to put on the freedesktop bug tracker. Alex
@All : As regards a blocker or not, I guess I still don't understand the subtleties of what qualifies as a blocker for the release despite having read the wiki here : http://wiki.documentfoundation.org/Release_Criteria The problem has existed since 3.3.0, so 3.3.1 shouldn't in theory have got released on the basis of the above criteria (despite my having already included it in the nominee bug list and Petr putting it back to 3.3.2), and now of course it will be pushed back again to 3.3.3. I can understand there being priority given to certain bugs and not others, but then the wiki page ought to reflect better the weighting given to each criteria into what becomes decisive in giving the green light for release and skipping awkward bugs like this one seems to be. Alex
Alex, I'm afraid - this works for me. Any chance to get the original odb again? (I opened test.odb, and tried both Query1 and Query12)
@Thorsten : New link : http://www.cijoint.fr/cjlink.php?file=cj201103/cij4vAJMeO.odb Alex
I'm running : LibreOffice 3.3.1 OOO330m19 (Build:8) tag libreoffice-3.3.1.2 System version : Mac OS X 10.6.6 (10J567) Kernel version : Darwin 10.6.0 Boot Volume : Macintosh HD Boot Mode : Normal Hostname : MacBookPro Secure virtual memory : active 64bit Kernel and extensions : Yes
Did a clean install of 3.3.2 RC1, and removed all old LibO user config directories. I can now open the reports (the missing line problem is still there though, but that's a separate issue). Closing this issue. Alex
changing status
closing
RESOLVED, FIXED or CLOSED bugs cant be KEYWORD NEEDINFO.