Hello, I've been in the list for a long time as a reader and after years I finally managed to get a development computer and restarted playing with current wine git.
There are about 15 bugs on bugzilla but none of them are related to this. I'm trying the list first before opening a bug. It's quite simple to reproduce, although I'm not sure if I can attach the hlp file here since it's from windows. The crash happens because the help file needs another help file. There is a button on the screen called Glossary that needs a file called glossary.hlp. If this file does not exist wine asks me to point it, if I answer No or yes and then cancel file selection wine crashes on an assert.
The following lines are displayed on the console: fixme:winhelp:WINHELP_GetWindowInfo Couldn't find window info for glossary winhelp.c:270: WINHELP_GetWindowInfo: Assertion `0' failed. wine: Assertion failed at address 0xb78f0424 (thread 003b), starting debugger...
The following lines are from file winhelp.c, around line 270. ... if (strcmp(name, "main") != 0) { WINE_FIXME("Couldn't find window info for %s\n", name); assert(0); return NULL; } ...
The function WINHELP_OpenHelpWindow does not resist WINHELP_GetWindowInfo returning NULL. That was why the assert(0) was added inside it to abort the program execution (as far as I see). There are 3 calls like this (one on winhelp.c and the others on macro.c):
... WINHELP_OpenHelpWindow(HLPFILE_PageByHash, hlpfile, lHash, WINHELP_GetWindowInfo(hlpfile, wndname), show); ...
My approach to fix this is quite simple: instead of splitting the above lines on different places and add a check for each of them the easier way is to simply make OpenHelpWindow resist null pointers and do not open anything because the user was already warned and asked for the nonexistent file. The proposed solution (if I may call adding one "if" a solution) is attached. If anyone has the problematic hlp file that was the cause to add the assert(0) please send me. Looks like the assert is there since wine 1.0 according to http://source.winehq.org/source/programs/winhlp32/winhelp.c?v=wine-1.0
Best wishes, Bruno
-- universe* god::bigbang (void); //and then it all began...
your proposal isn't fixing the problem, it just hides it
what seems (to be confirmed) to happen is that winhelp should better support secondary windows as 'glossary' (or have fallback for those) as it does for primary window (called 'main') (or support defining window name when opening a file)
can you send me (in private) the relevant .hlp files (main one and glossary.hlp) I'll have a deeper look
On Fri, Jul 22, 2011 at 06:26, Eric Pouech eric.pouech@orange.fr wrote:
your proposal isn't fixing the problem, it just hides it
I was waiting for someone to reply saying that because I see it happening dozens of times in the list, but I guess it's better to start sending a patch them never sending any.
At first I thought I would be hidding the problem too, but after checking windows does the same (doesn't open anything because there's no file) I thought it was fixed.
what seems (to be confirmed) to happen is that winhelp should better support secondary windows as 'glossary' (or have fallback for those) as it does for primary window (called 'main') (or support defining window name when opening a file)
From what I understood from the source what happens is that
WINHELP_GetWindowInfo receives the parameter "glossary" as name and hlpfile = NULL because the file was not found. So if the file was not found there's nowhere to look for, and in this case there can't be any fallback because it's a different file.
can you send me (in private) the relevant .hlp files (main one and glossary.hlp) I'll have a deeper look
-- Eric Pouech
-- Bruno
I've just sent a patch that should fix it. A+
I see, thank you. You protected the local calls instead of protecting the called function, I guess it's better this way.
Best wishes, Bruno
On Sun, Jul 31, 2011 at 03:55, Eric Pouech eric.pouech@orange.fr wrote:
I've just sent a patch that should fix it. A+
-- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)