Bug 47320 - DrMemory windows warning cleanup ...
Summary: DrMemory windows warning cleanup ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected)
Master old -3.6
Hardware: Other All
: medium major
Assignee: Not Assigned
Keywords: difficultyMedium, easyHack, skillCpp, topicCleanup
Depends on:
Blocks: Memory
  Show dependency treegraph
Reported: 2012-03-14 13:54 UTC by Michael Meeks
Modified: 2021-01-05 10:45 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:

drmemory log (12.07 KB, text/plain)
2012-03-14 13:56 UTC, Michael Meeks
*big* uninitialized memory log with lots of duplicates gzipped (529.36 KB, application/x-gzip)
2012-03-16 07:50 UTC, Michael Meeks

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Meeks 2012-03-14 13:54:23 UTC
We regularly run LibreOffice and our extensive test suite through valgrind on Linux, which dungs out -tons- of errors and problems.

However - on Windows, we don't get anything like the same level of coverage.

If you install 'DrMemory' - http://www.drmemory.org/ (choose to add it in your path works best).

Then run:

drmemory -- soffice.exe

You should get a long slew of uninitialized warnings, and wrong malloc/delete pairings and so on I'll attach a very limited sample of these. You really want to install a pre-compiled Windows build from libreoffice-3-5-1 with debugging symbols:


Then you can get nice precise stack traces. Then it'd be great to try to hunt down the errors. Unfortunately uninitialized memory errors can be hard to find - they can propagate through the code at great length, and need tracing right back to the first non-initialization.

Thanks !
Comment 1 Michael Meeks 2012-03-14 13:56:28 UTC
Created attachment 58447 [details]
drmemory log

a -very- truncated set of results from a run with uninitialized warnings disabled based on the libreoffice-3-5 branch from hash: 

commit 369aea7f7402e9dc98e9347ae58999dad2d21652
Author: Noel Power <noel.power@novell.com>
Date:   Thu Mar 1 12:10:56 2012 +0000

    fix crash using instances dialog of dataform navigator fdo#44816
Comment 2 Michael Meeks 2012-03-14 14:01:06 UTC
We should also (as a 2nd step) work out what is wrong with our GDI usage - which seems to crash/burn drmemory quite severely - I suspect we are busting something in their memory hierarchy somehow.
Comment 3 Michael Meeks 2012-03-16 06:55:47 UTC
There are an odd couple of warnings here that need examining too I suppose - peprhas omethreading issue (?) or ... unwinding whatt he errro actually means I guess:

~~Dr.M~~ Error #1: WARNING: GDI usage error: DC 0x40010fdb that contains selected object being deleted
~~Dr.M~~ # 0 system call NtUserCallOneParam.RELEASEDC
~~Dr.M~~ # 1 vcllo.dll!WinSalGraphics::getNativeControlRegion                     [c:\libo\vcl\win\source\gdi\salnativewidgets-luna.cxx:1416]
~~Dr.M~~ # 2 vcllo.dll!SalGraphics::GetNativeControlRegion                        [c:\libo\vcl\source\gdi\salgdilayout.cxx:789]
~~Dr.M~~ # 3 vcllo.dll!OutputDevice::GetNativeControlRegion                       [c:\libo\vcl\source\gdi\outdevnative.cxx:325]
~~Dr.M~~ # 4 vcllo.dll!StatusBar::CalcWindowSizePixel                             [c:\libo\vcl\source\window\status.cxx:1702]
~~Dr.M~~ # 5 vcllo.dll!StatusBar::ImplInit                                        [c:\libo\vcl\source\window\status.cxx:166]
~~Dr.M~~ # 6 vcllo.dll!StatusBar::StatusBar                                       [c:\libo\vcl\source\window\status.cxx:174]
~~Dr.M~~ # 7 fwklo.dll!framework::LayoutManager::implts_createProgressBar         [c:\libo\framework\source\layoutmanager\layoutmanager.cxx:918]
~~Dr.M~~ # 8 fwklo.dll!framework::LayoutManager::createElement                    [c:\libo\framework\source\layoutmanager\layoutmanager.cxx:1555]
~~Dr.M~~ # 9 fwklo.dll!framework::StatusIndicatorFactory::impl_createProgress     [c:\libo\framework\source\helper\statusindicatorfactory.cxx:479]
~~Dr.M~~ #10 fwklo.dll!framework::StatusIndicatorFactory::initialize              [c:\libo\framework\source\helper\statusindicatorfactory.cxx:144]
~~Dr.M~~ #11 fwklo.dll!framework::Frame::initialize                               [c:\libo\framework\source\services\frame.cxx:610]
~~Dr.M~~ Note: @0:04:26.648 in thread 3896
~~Dr.M~~ Error #2: WARNING: GDI usage error: deleting an object 0x9f0a0b5a that is selected into DC
~~Dr.M~~ # 0 system call NtGdiDeleteObjectApp
~~Dr.M~~ # 1 vcllo.dll!WinSalGraphics::SetFont                     [c:\libo\vcl\win\source\gdi\salgdi3.cxx:1691]
~~Dr.M~~ # 2 vcllo.dll!OutputDevice::ImplReleaseGraphics           [c:\libo\vcl\source\gdi\outdev.cxx:739]
~~Dr.M~~ # 3 vcllo.dll!Window::~Window                             [c:\libo\vcl\source\window\window.cxx:4538]
~~Dr.M~~ # 4 vcllo.dll!DockingWindow::~DockingWindow               [c:\libo\vcl\source\window\dockwin.cxx:482]
~~Dr.M~~ # 5 vcllo.dll!ToolBox::~ToolBox                           [c:\libo\vcl\source\window\toolbox.cxx:1815]
~~Dr.M~~ # 6 vcllo.dll!DecoToolBox::calcMinSize                    [c:\libo\vcl\source\window\menu.cxx:620]
~~Dr.M~~ # 7 vcllo.dll!DecoToolBox::DecoToolBox                    [c:\libo\vcl\source\window\menu.cxx:576]
~~Dr.M~~ # 8 vcllo.dll!MenuBarWindow::MenuBarWindow                [c:\libo\vcl\source\window\menu.cxx:5179]
~~Dr.M~~ # 9 vcllo.dll!MenuBar::ImplCreate                         [c:\libo\vcl\source\window\menu.cxx:3352]
~~Dr.M~~ #10 vcllo.dll!SystemWindow::SetMenuBar                    [c:\libo\vcl\source\window\syswin.cxx:957]
~~Dr.M~~ #11 fwklo.dll!framework::LayoutManager::createElement     [c:\libo\framework\source\layoutmanager\layoutmanager.cxx:1535]
~~Dr.M~~ Note: @0:09:26.966 in thread 3896

running with -ignore-asserts -no_check_gdi gets past this into other erors though - perhaps it's just a big in drmemory's gdi checking code :-)
Comment 4 Michael Meeks 2012-03-16 07:50:32 UTC
Created attachment 58562 [details]
*big* uninitialized memory log with lots of duplicates gzipped
Comment 5 Florian Reisinger 2012-05-18 08:20:25 UTC
Removed EASYHACK from summary
Comment 6 Björn Michaelsen 2013-10-04 18:47:47 UTC
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.

see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Comment 7 Robinson Tryon (qubit) 2013-10-19 00:22:36 UTC Comment hidden (obsolete)
Comment 8 Robinson Tryon (qubit) 2015-12-10 11:40:51 UTC Comment hidden (obsolete)
Comment 9 Robinson Tryon (qubit) 2016-02-18 14:51:53 UTC Comment hidden (obsolete)
Comment 10 Julien Nabet 2020-05-03 14:03:12 UTC
I wanted to give a try at DrMemory on Linux, here's what I did:
- download DrMemory-Linux-2.3.0-1 from https://github.com/DynamoRIO/drmemory/wiki/Downloads
- gunzip + untar it
- launch ~/projects/drmemory/DrMemory-Linux-2.3.0-1/bin64/drmemory -- ./soffice.bin

I got:
~~Dr.M~~ Dr. Memory version 2.3.0
~~Dr.M~~ Error #1: UNINITIALIZED READ: reading register rcx
~~Dr.M~~ # 0 libpthread.so.0!__pthread_initialize_minimal_internal
~~Dr.M~~ # 1 libpthread.so.0!_init          
~~Dr.M~~ # 2 ld-linux-x86-64.so.2!?                             +0x0      (0x00007faa482d032c <ld-linux-x86-64.so.2+0xf32c>)
~~Dr.M~~ # 3 ld-linux-x86-64.so.2!?                             +0x0      (0x00007faa482d04de <ld-linux-x86-64.so.2+0xf4de>)
~~Dr.M~~ # 4 ld-linux-x86-64.so.2!?                             +0x0      (0x00007faa482c20ca <ld-linux-x86-64.so.2+0x10ca>)
~~Dr.M~~ Note: @0:00:20.755 in thread 151164
~~Dr.M~~ Note: instruction: cmp    %rcx $0xffffffffffffffff
then still nothing after some minutes, LO doesn't launch

In my autogen.input, these are present:
I'm on Debian x86-64 with master sources updated today.

Is it because I use clang instead of Gcc? Anything I missed about config?
Comment 11 Buovjaga 2021-01-05 07:36:30 UTC
(In reply to Julien Nabet from comment #10)
> I wanted to give a try at DrMemory on Linux, here's what I did:
> ...
> Is it because I use clang instead of Gcc? Anything I missed about config?

I use GCC and it refused to launch with soffice.bin, but it failed similarly when I tried with GIMP. I guess it just doesn't work very well on Linux.
Comment 12 Michael Meeks 2021-01-05 10:45:44 UTC
The real value of DrMemory is/was on Windows - where it can give insight into all manner of bad windows API usage, leakage of OS handles and where those came from etc. that are really hard to find in other ways =) For Linux - I think we have pretty good coverage of that stuff with valgrind.