Description: Open a .pps file diporama start right click to enter edit mode in display mode ask for slides mosaic crash occurs with .ppt no problem Steps to Reproduce: 1.open .pps file 2.right click to switch to edit mode 3.in display mode select slides mosaic Actual Results: crash report send Expected Results: display mosaic of diapos as in LO 5.1.x release Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.0
On pc Debian x86-64 with LO Debian package 5.2.4, I don't see these options. I openened a pps file then diaporama started. I right clicked and had these: - Next - Go to Slide - Mouse pointer as Pen - Pen width - Change pen color... - Erase all ink on slide - Screen - Edit presentation - End Show So I chose "Edit presentation" but then where's display mode, slides mosaic?
Sorry, I use a french version of LO i have translated in menu bar "affichage" by display mode and "trieuse de diapositives" by slide mosaic may be slide sorter is better best regards
Thank you for your quick feedback. I don't reproduce this with LO Debian package 5.2.4. Could you apply advice from here: https://wiki.documentfoundation.org/QA/FirstSteps and give us a new feedback?
in about i have UI:defaults i have renamed my profile then retry bug is présent i use LO on Windows 10 1607 64 bits
exactly in about i have UI Render : par défaut
Would it be possible you retrieve a backtrace by following advice from https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#Windows:_How_to_get_a_backtrace ? Meanwhile, I'll put back UNCONFIRMED so other may give it a try.
I forgot to ask if you reproduced this only with a specific pps or with any pps file? I mean, do you reproduce this with a brand pps file of 2 slides containing only "test1" and "test2"? If you reproduce this only with a specific pps, would it be possible you attach it to the bugtracker by using this link: https://bugs.documentfoundation.org/attachment.cgi?bugid=104870&action=enter ? (have in mind that any attachment is automatically public so remove any confidential/private part).
problem arise with any .pps simple or complex another information if i rename file to .ppt extension ,there is no bug i amconfused about complexity for enter debug mode an obtain backtrace bug report sended automaticaly by Lo is not sufficent ?
crash report crashreport.libreoffice.org/stats/crash_details/138a6327-9578-459d-9cf0-501c38917d7c
As suggested i have build a sample test.pps with two simple slides now i have made the following tests 1) open directly test.pps no bug 2) wia email i send to me test.pps as attachement 3) from thunderbird ask open attachement test.pps bug arise 4) attachement test.pps is stored in temp folder open it bug arise 5) reopen original test.pps no bug ????????? hex compare of two files does not show any difference on first pages .pps i ordinary open comes from emails what happen when they are embeded ?
last interesting test 1 open any .pps from email bug arises 2 now .pps is stored in temp file 3 open it from temp file 4 right click enter edit présentation 5 save .pps with another name in same folder 6 i can see that sizes of two are different 7 open saved .pps and re test no bug ???????????????? so i think that embedding process to store .pps in email alter it but in temp file if i rename the bugged one from .pps to .ppt and open it no bug ??
Just to be sure, if the file is on a directory and open it directly from it, no problem but, if you open the file from an email, it crashes, is that it? Which mailer do you use (Thunderbird, Outlook, other)?
exactly results are same if i open .pps from thunderbird or directly from laposte.net webmail but embeding of pps is performed by thunderbird i re test now embeding made by webmail same result
I could reproduce this with a pps I sent to myself that I opened on Thunderbird.
Created attachment 129906 [details] bt with symbols On pc Debian x86-64 with master sources updated today, I could reproduce this.
I tried with an odp made from scratch (2 slides with "test1" in slide 1 and "test2" in slide 2), I could reproduce this following these steps: 1) Send myself the odp by mail 2) Launch the odp from mailer 3) Type F5 (without this step, I don't reproduce the crash) => slideshow begins 4) Finish the slideshow and type "Esc" to exit it 5) Select View, "Slide Sorter" => Crash Michael: interestingly, if I comment block which follows: // Determine if the panel can be displayed. (see http://opengrok.libreoffice.org/xref/core/sfx2/source/sidebar/SidebarController.cxx#607), I don't reproduce the crash. This block comes from https://cgit.freedesktop.org/libreoffice/core/commit/?id=603c089e4261a028d9ea70012cb5b1f4effcb545 which itself comes from https://cgit.freedesktop.org/libreoffice/core/commit/?id=aae247a34cd6f3bf421e57bbec08837d73ddf258 I made some tests with gdb it seems sometimes we enter to "continue" part and so it seems there are missing info then. (rPanelContexDescriptor.msId=SlideBackgroundPanel and rPanelContexDescriptor.msId=SdLayoutsPanel)
Hmm; well - looks like we get a defunct panel - the NULL ptr in the UnoPanel's mpPanel - is suggestive - however; I don't really see where that gets cleared / disposeAndCleared - unless it is itself freed. I suspect a valgrind trace might give a better idea of where the memory badness starts to happen; but ... Ultimately, nothing obvious jumps out at me, but I have bad memories of similar pieces of code to this ;-) thanks for chasing it !
(In reply to Michael Meeks from comment #17) > Hmm; well - looks like we get a defunct panel - the NULL ptr in the > UnoPanel's mpPanel - is suggestive - however; I don't really see where that > gets cleared / disposeAndCleared - unless it is itself freed. I suspect a > valgrind trace might give a better idea of where the memory badness starts > to happen; but ... >... Thank you for your feedback Michael. If I can choose "soffice" binary generated by building sources when opening the attachment from my mailer (icedove) then attach process to gdb (that's how I did to retrieve a bt), how can I ask for a Valgrind trace? (env var?) Indeed, I can't just run Valgrind the usual way here.
Hi Julien - so, worth checking if you can reproduce when you already have a LibreOffice running =) When you launch from the E-mail client - if there is no soffice running - you should inherit it's environment - which -may- change something. If that is indeed the cause; then having launched it from the mailer if you do: strings /proc/<pid-of-that-process>/environ | tee /tmp/environment will give you something that (with a bit of hacking) you can source into an environment to replicate that thing before running it manually =) Otherwise - if that is not needed, just running under valgrind before launching from the mailer would work I guess. I'd be interested though - if we can't get valgrind to work - to look at the parent of the frame where the 'this' pointer is NULL - to see if that object looks alive / initialized: clearly we should be. It looks like: void SAL_CALL SfxUnoPanel::setTitle( const OUString& newTitle ) throw(uno::RuntimeException, std::exception) Is tooled up to cope with a NULL pTitleBar: PanelTitleBar* pTitleBar = mpPanel->GetTitleBar(); if (pTitleBar) ... We could extend that to cope with a NULL mpPanel - but ... really, I'm rather concerned as to how mpPanel becomes NULL - unless it is initialized to that in the constructor [ which is possible I guess ]. Perhaps just a: if (mpPanel) { } above the substance there ? ;-)
Created attachment 130399 [details] Valgrind trace Sorry Michael for not having responded earlier. Anyway, I could reproduce the problem with master sources updated today (5e0e27e758e6f7fa325f36e6e51540e10bab0fdc) I launched soffice from console, then I opened the odp file by telling to Icedove to use this same soffice and had a crash. I attached Valgrind trace which is quite short (compared to what I usually retrieve) but interesting.
Hello, This bug is also present in last LO 5.3.0.3 Best regards
Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=58d4a3122ce59c68aa7a4b7e09f76bf15865be9b tdf#104870 - keep reference on the TitleBar while setting title. It will be available in 5.4.0. 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.
Hello, Is this bug fixed? If so, could you please close it as RESOLVED FIXED?
Following Xisco's comment, let's put this one to NEEDINFO.
(In reply to Julien Nabet from comment #24) > Following Xisco's comment, let's put this one to NEEDINFO. I don't think setting the status to NEEDINFO is correct here. This status is only used when asking for further information to the reporter in order to get the bug confirmed and this bug was already confirmed. Changing it back to NEW
Hello every body This bug is again present in last 5.4.0.3 release in windows 10 best regards
Bug is again present in LO 5.4.2
Bug is again present in LO 5.4.3.2
yes, we still have crashes in the latest version. 52 reports in 5.4.3.2 -> http://crashreport.libreoffice.org/stats/signature/sfx2::sidebar::Panel::GetTitleBar()
Ok, I think I found a way to reproduce it. 1. Create a new file in impress 2. Save it ( it can be empty ) 3. Deselect Edit Mode from Edit menu 4. Change to Notes Master CRASH!!
Created attachment 138534 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today and following Xisco's step by step process, I could reproduce this. The pb is mpPanel seems to be null or deleted here: 72 VclPtr<PanelTitleBar> pTitleBar = mpPanel->GetTitleBar(); 73 if (pTitleBar) 74 pTitleBar->SetTitle(newTitle);
Hello, Bug is again present in LO5.4.4.2 but which is better expected display appear a few seconds then CRASH
Regression introduced by: author Susobhan Ghosh <susobhang70@gmail.com> 2016-06-14 10:28:01 +0200 committer Yousuf Philips <philipz85@hotmail.com> 2016-06-18 09:20:35 +0000 commit 9579fa7bddc11deeb00474cad2203ac613c1c3f8 (patch) tree 8f733b4a58e8d0902c44fc5f71b7dec36a628a4a parent 8389616baa8c03f878be5dfeb0a9f2db546bb66f (diff) tdf#86759 and tdf#89466: Enable Page Background Panel for Draw Rename Slide Background Panel to Slide in Impress. Reorder Properties Deck Reviewed-on: https://gerrit.libreoffice.org/26159 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de> Function to change sidebar panel title, via UNO API Bisected with: bibisect-linux-64-5.2 Adding Cc: to Susobhan Ghosh I tested it locally and removing the block case EventMultiplexerEventId::ViewAdded in SlideBackground.cxx avoids the crash. @Tamas, recently, you worked in this part of the code, do you know why it's crashing?
Tamás Zolnai committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=23a83639f5a06708074b13bc13ea4f6f819f55f0 tdf#104870 - Impress crashes switching views in read-only mode It will be available in 6.1.0. 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.
Tamás Zolnai committed a patch related to this issue. It has been pushed to "libreoffice-5-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6cc44459833deec6a54a0ed8b0572d345d3e7425&h=libreoffice-5-4 tdf#104870 - Impress crashes switching views in read-only mode It will be available in 5.4.5. 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.
Tamás Zolnai committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ffca194466e08691e381d642b07154121edefece&h=libreoffice-6-0 tdf#104870 - Impress crashes switching views in read-only mode It will be available in 6.0.0.2. 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.
@Tamás Zolnai, do no forget to close this one...