Bug 103926 - Crash in: vcl::Window::ImplGrabFocus(GetFocusFlags)
Summary: Crash in: vcl::Window::ImplGrabFocus(GetFocusFlags)
Status: RESOLVED DUPLICATE of bug 105121
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
5.2.3.1 rc
Hardware: x86 (IA32) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: haveBacktrace, regression
Depends on:
Blocks:
 
Reported: 2016-11-14 15:09 UTC by Hans Gerstenkorn
Modified: 2017-10-11 09:31 UTC (History)
7 users (show)

See Also:
Crash report or crash signature: ["vcl::Window::ImplGrabFocus(GetFocusFlags)"]


Attachments
Anonymized copie of the LO-DB with the described errors (666.35 KB, application/vnd.sun.xml.base)
2016-11-25 14:53 UTC, Hans Gerstenkorn
Details
Screenshot form resource monitor with opend database (51.81 KB, image/png)
2016-11-26 08:44 UTC, Hans Gerstenkorn
Details
LO CPU performance (22.51 KB, image/png)
2016-11-26 18:55 UTC, Hans Gerstenkorn
Details
LO soffice bin etc... (23.70 KB, image/png)
2016-11-26 18:56 UTC, Hans Gerstenkorn
Details
GDI_status (38.82 KB, image/png)
2016-11-27 09:34 UTC, Hans Gerstenkorn
Details
Soffice only LO (45.96 KB, image/png)
2016-11-27 10:13 UTC, Hans Gerstenkorn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hans Gerstenkorn 2016-11-14 15:09:13 UTC
This bug was filed from the crash reporting server and is br-2b008d1c-2ef0-4378-b75a-ceedac79ca36.
=========================================
LO Version: 5.2.3.1, OS Microsoft Windows 10 Pro, Version 10.0.14393 Build 14393, Lenovo ThinkPad T430
----------------------------------------------------
Often during to enter values within a form or to edit a form, LO becomes "frozen" = LO uses CPU nearly round 30% and doesn't stop, I have to cancel with the task manager. I can't find out the problem, otherwise I don't know the way to find out the problem of this DB. The DB has actual 501 kB. 

The same Problem will occur when I move an embedded table in the form and move it over an existing other embedded table.....

Within both ways it is not usually that an report would be generated.
Comment 1 Buovjaga 2016-11-24 10:07:00 UTC
Hans: please attach an example database where this occurs.

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the database.
Comment 2 Hans Gerstenkorn 2016-11-24 18:09:52 UTC
Hi, I'm not a LO-specialist, please let me know an easy way, how to crate an example of my database so that the database will be anonymized. For example; is there any way within a few commands to delete the contents of all tables ore most of all. The database has nearly 40 tables and most of them have links to documents or pictures in other directories on my computer. Mostly of the links are "speaking" and so they are personalized. So I've to delete the contents and then to make some examples.
I have to say many thanks for helping, so that I can create an eaxample of my database.

Please see also newest bugs: 
crashreport.libreoffice.org/stats/crash_details/f1ef159b-1f9c-480c-90df-0c3272abe808
and
crashreport.libreoffice.org/stats/crash_details/63502341-f9c1-4553-8e42-c70158fde9e7
Comment 3 Buovjaga 2016-11-24 19:30:49 UTC
(In reply to Hans Gerstenkorn from comment #2)
> Hi, I'm not a LO-specialist, please let me know an easy way, how to crate an
> example of my database so that the database will be anonymized. For example;
> is there any way within a few commands to delete the contents of all tables
> ore most of all. The database has nearly 40 tables and most of them have
> links to documents or pictures in other directories on my computer. Mostly
> of the links are "speaking" and so they are personalized. So I've to delete
> the contents and then to make some examples.

I can only think that you would have to create a new database from scratch with some dummy data.
Comment 4 Hans Gerstenkorn 2016-11-24 22:44:11 UTC
o.K., I'll try it, but it could be that I need a few days... Please have a little bit time , thanks :-)
Comment 5 Alex Thurgood 2016-11-25 08:24:49 UTC
*** Bug 104149 has been marked as a duplicate of this bug. ***
Comment 6 Alex Thurgood 2016-11-25 08:34:54 UTC
CCing Michael, as this looks like another VCL issue - something about the mouse not receiving correct focus after disposing a previous window frame ?
Comment 7 Alex Thurgood 2016-11-25 08:35:58 UTC
Setting to new, because we have a backtrace in the crash report
Comment 8 Alex Thurgood 2016-11-25 08:52:05 UTC
So, my rudimentary understanding of this is that :

svt::CheckBoxControl calls dispose when the window containing the control is closed

this should call in turn Control::dispose and then vcl::Window::dispose, which should in turn lead to the focus being re-attributed to the next relevant window or the object (or a pointer to that) of wherever the mouse focus happens to be

but something goes wrong in the calls to 

vcl::Window::ImplGrabFocus(GetFocusFlags) 

vcl::Window::GrabFocus

and

vcl::Window::ImplGrabFocus(GetFocusFlags) 

As I don't really understand the difference between 

GrabFocus at mouse.cxx#383
and
CompatGetFocus at mouse.cxx#201

I'm unfortunately none the wiser.
Comment 9 Hans Gerstenkorn 2016-11-25 14:53:19 UTC
Created attachment 129006 [details]
Anonymized copie of the LO-DB with the described errors

Hi to all spcialists, now I'v got the first reproducible

I copied my LO-database and anonymized it. Then I tried to specific and reproduce the bug when it becomes "frozen", but now it doesn't work because erytime when I opened a quiery for example "VerbrauchswerteWasserVerbraucher_Engeben_Ändern_v" or "Zaehlerwerte_Wasser_Eingeben" than the db "said" "Program doesnt work properly " and I've to restart - then it was an bugreport created. It is reproducible, pleas try it. Hopefully You'll find also the other bugs....
Comment 10 Robert Großkopf 2016-11-25 18:06:53 UTC
(In reply to Hans Gerstenkorn from comment #9)> 
> I copied my LO-database and anonymized it. Then I tried to specific and
> reproduce the bug when it becomes "frozen", but now it doesn't work because
> erytime when I opened a quiery for example
> "VerbrauchswerteWasserVerbraucher_Engeben_Ändern_v" or
> "Zaehlerwerte_Wasser_Eingeben" than the db "said" "Program doesnt work
> properly " and I've to restart - then it was an bugreport created. It is
> reproducible, pleas try it. Hopefully You'll find also the other bugs....

The two examples aren't queries. I found forms with this name in the document. Could start the forms without any problem on OpenSUSE 42.1 64bit rpm Linux with LO 5.2.3.3 64bit. So a special Windows-problem.
Comment 11 Michael Meeks 2016-11-25 18:33:48 UTC
Looks very odd; the

void Window::ImplGrabFocus( GetFocusFlags nFlags )

holds a hard reference on 'this' - never a great sign ;-) but it does:

    // some event listeners do really bad stuff
    // => prepare for the worst
    VclPtr<vcl::Window> xWindow( this );

So it is extraordinary that subsequently (at least this is the only interpretation I can give) that 'this' is invalid memory at a later date. Crazy stuff. Presumably then it is memory corruption, or a threading issue of some kind. As such we need a drmemory or valgrind trace of what is going on in a debugging symbols build ...
Comment 12 Michael Meeks 2016-11-25 22:09:50 UTC
Annoying; running under valgrind - I get:

"The connection to the data source "Energie_Bug" could not be established"

which makes this hard to repeat; if we could do so with a firebird DB life might be better I guess ...
Comment 13 Hans Gerstenkorn 2016-11-26 07:00:57 UTC
Robert ist absolutely right, of course! I'm so sorry about my mistake, naturally I mean forms...
Comment 14 Hans Gerstenkorn 2016-11-26 08:44:45 UTC
Created attachment 129018 [details]
Screenshot form resource monitor with opend database
Comment 15 Hans Gerstenkorn 2016-11-26 14:41:46 UTC
Hello everybody,

I just see that I haven't saved my comment from today. So:

I suspect that the problem is my notebook. I've read in the comments that it may be synonymous memory problems and so I've the database on an older DELL Vostro tried and saw, the DB have been running perfectly. I'll still test extensively, but so far I could not reproduce the error, but probably again on the notebook.

At the memory - at least the size does not lie, with the Vostro it is only 1GB RAM (32 Bit, Win 10 Pro), the Thinkpad has 8GB RAM, please see the screenshot.

Thanks for helping, now may be I have to live with it, because to find such a mistake is probably only specialists or it will be a good reason to change the notebook..... ....

Have a nice Advent time :-) dietrich
Comment 16 Michael Meeks 2016-11-26 16:31:40 UTC
Quick query - can you add the 'gdi handles' field to the task manager - and see how many process handles soffice.bin is using - if it is around 10k - then this could be the issue ...
Comment 17 Hans Gerstenkorn 2016-11-26 18:55:27 UTC
Created attachment 129038 [details]
LO CPU performance
Comment 18 Hans Gerstenkorn 2016-11-26 18:56:00 UTC
Created attachment 129039 [details]
LO soffice bin etc...
Comment 19 Hans Gerstenkorn 2016-11-26 19:01:59 UTC
Hi Michael,

I added 2 attachments so You can see the soffice.bin performance...
But I have a little problem to add the GDI column. There is no possibility to add it in the microsoft explorer or recource monitor. I'll try to find out and hopefully as soon as possible I'll add it a little bit later ...
Comment 20 Michael Meeks 2016-11-26 22:25:31 UTC
This is the guy to read: https://blogs.msdn.microsoft.com/dsui_team/2013/04/23/debugging-a-gdi-resource-leak/ =)
Comment 21 Hans Gerstenkorn 2016-11-27 09:34:33 UTC
Created attachment 129046 [details]
GDI_status

Within Windows 10 Pro the selection of column e.g. GDI or so You will find in the Windows-Explorer unter the "details" tab!
Comment 22 Hans Gerstenkorn 2016-11-27 09:35:13 UTC
Hi Michael,

it was not so easy, but by trying hard I've still found where the columns for the selection hide. Unlike previous versions of Windows, this selection in "Windows 10 Pro" is no longer found in the "Process" tab, but in the "Details" tab. This is unfortunately not specified anywhere in Microsoft and in all references (google-search) the old taskmanager views are shown ...

Well, I've now created a current screenshot with an open database, and of course I am asking myself what is to be done, shall I change the capacity in the registry key, I've just read that each process under Windows has a maximum of 10,000 GDI objects per user, and by the way, I don't know why the DB needed so many objects ....?
Comment 23 Hans Gerstenkorn 2016-11-27 10:13:03 UTC
Created attachment 129048 [details]
Soffice only LO

Now I cancelled OO!
Comment 24 Hans Gerstenkorn 2016-11-27 10:15:03 UTC
I saw, OO started with Windows  - a few month I changed from OO to LO but I didn't uninstall OO - may be that was the problem?! We w'll see...
Comment 25 Michael Meeks 2016-11-28 11:15:45 UTC
Thanks - doesn't look like GDI resource exhaustion. I guess the next step is to run this under drmemory with a dbgutil build - except (I suspect) the dbgutil build fails on Windows due to some assertions. Hmm =) ...
Comment 26 Hans Gerstenkorn 2016-11-28 16:20:26 UTC
Hi Michael,
it is desperate, but I simply lack the knowledge to work with the mentioned programs. I've "drmemory" installed, but then how is to going on? I just miss the specific knowledge, certainly to mention and work with dbgutil .... 
I am just an ordinary user with a little bit = very low ideas of the depths of the systems. I'm fighting to find out the problem, but I think the way would be to difficult and I can't see the way what is to do. The other little "problem" is the language, often I'm thinking I've lost most of my vocabulary, because school time has gone more than 50 years ago.... Thanks for Your help and it would be great, if You've an another idea which could be helping for me. So if there is no possibility, I've to use the database on another hardware at my home - it's only my one and the first I've tried instead of a lot of xls-sheets. If it would be nice to find out the error but if the way to hard so I've to accept...  :-) Hans
Comment 27 Buovjaga 2016-11-28 16:34:42 UTC
Hans: here is a dbgutil build: http://dev-builds.libreoffice.org/daily/master/win-x86@39/current/

Try first, if you can make it crash.
Comment 28 Hans Gerstenkorn 2016-11-28 18:30:59 UTC
The database works perfectly, what a surprise, or not, may be someone has turned on it :-)?! I've installed the newest test version parallel and the last work steps, which always led to a crash, nothing(!) this version of  that database works very well, perfect! With the previous version 5.2.3.3 it still produces the errors.

So I'll try in the next time all possibilities, but I am very glad to have the new version. Now I'm missing only a hint as I use the language tool 3.5. I Can't install it, may be this tool doesn't work within the newest test version? It's not really a problem, though I'm often click at the wrong button because they switched in other language....

I am so hopefully, that all my bugs are in the past, so I'll try and check  all possibilities in my database and will give You feedback in next time. 

 :-) Thank you already now
Comment 29 Alex Thurgood 2016-11-29 14:33:36 UTC
Can we close this as RESOLVED WFM then, in light of comment 28 ?
Comment 30 Hans Gerstenkorn 2016-11-29 14:43:02 UTC
If it's possible, let me try some more possibilities, I think I need only a few days, than I'll be back with an comment, many thanks :-) hans
Comment 31 Hans Gerstenkorn 2016-12-01 13:03:30 UTC
@Alex: I think, this can be closed down. I couldn't reproduce the scrash, but yesterday I've got another little Problem, but I think it ist my notebook, If I tried on my PC and if it'll be also there, I'll open a new question in the LO Forium.
Many thanks to all and have a nice Advent :-) hans
Comment 32 Buovjaga 2016-12-01 14:05:52 UTC
Thanks, closing.
Comment 33 Alex Thurgood 2017-05-12 06:55:17 UTC
*** Bug 107781 has been marked as a duplicate of this bug. ***
Comment 34 Alex Thurgood 2017-05-12 06:57:12 UTC
Re-opening due to duplicate bug 107781
Comment 35 Xisco Faulí 2017-07-10 18:04:46 UTC
*** Bug 108229 has been marked as a duplicate of this bug. ***
Comment 36 Xisco Faulí 2017-07-10 18:05:01 UTC
*** Bug 108184 has been marked as a duplicate of this bug. ***
Comment 37 Julien Nabet 2017-10-11 08:43:35 UTC
Alex/Xisco: since this one can't be reproduced, I propose to:
- close it
- reopen tdf#107781
- put tdf#108184 + tdf#108229 as dup of tdf#107781
What do you think?
Comment 38 Maxim Monastirsky 2017-10-11 09:31:32 UTC
I believe it's a dup of Bug 105121.

*** This bug has been marked as a duplicate of bug 105121 ***