Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#9937 closed defect (fixed)

MSW - StackWalker - Linker error (release mode)

Reported by: arst Owned by:
Priority: low Milestone: 2.9.0
Component: wxMSW Version: stable-latest
Keywords: MSW stackwalker release mode Cc:
Blocked By: Blocking:
Patch: yes


Building wxMSW in release mode, with wxUSE_ON_FATAL_EXCEPTION==0 leads to a linker error.

The patch fixes the error, but maybe the file as a whole should be skipped in this case.



Attachments (1)

stackwalker-msw.patch download (848 bytes) - added by arst 13 years ago.

Download all attachments as: .zip

Change History (9)

Changed 13 years ago by arst

comment:1 Changed 13 years ago by vadz

  • Priority changed from normal to low
  • Status changed from new to infoneeded_new

Could you please show the exact error message? I don't really understand what's going on here, wxStackWalker should work even if wxUSE_ON_FATAL_EXCEPTION is off (although if the latter is on, then the former must be available).


comment:2 follow-up: Changed 13 years ago by arst

  • Status changed from infoneeded_new to new

There linker error is the one linker error I know of : Symbol not found.

It seems to me the variable is declared as extern in each file (do grep -n wxGlobalSEInformation in the src/msw directory). It seems to me that the compiler in some cases emits a global symbol, even if all declarations are extern.

In stackwalk.cpp it is accessed without precompiler guard wxUSE_ON_FATAL_EXCEPTION.

And for some reason the variable is never declared in this case, leading to the linker error.

Also, what is this line is confusing (main.cpp, around line 100):

  extern EXCEPTION_POINTERS *wxGlobalSEInformation = NULL;

(You should not assign a value to an extern global variable at global scope, and, a global pointer is already NULL per default).



comment:3 in reply to: ↑ 2 Changed 13 years ago by vadz

  • Resolution set to fixed
  • Status changed from new to closed

Replying to arst:

There linker error is the one linker error I know of : Symbol not found.

Well, there are plenty of others but most importantly you didn't mention which symbol wasn't found. From the latest comment it seems it's wxGlobalSEInformation but it would have been easier to just paste the error message...

Anyhow, should be fixed in r55593, this variable indeed shouldn't be used if wxUSE_ON_FATAL_EXCEPTION==0. Please test and reopen if you still have any problems, thanks.

comment:4 Changed 13 years ago by arst

The patch puts #ifdef around two C++ statements. One of them is an extern declaration. Together with a linker error there are not so many alternatives.

I don't feel good about spending time about spending more time on a bug report, when it seems like no-one made some effort to look at or understand the patch. 



comment:5 Changed 13 years ago by vadz

Come on, this is really ridiculous. You can't be bothered to paste the error message in the bug report or even mention the error which your patch is supposed to fix and you blame me for not putting enough effort in understanding it?

I do agree, I sure could have reverse-engineered your patch. I could also have fixed the bug myself. In fact why do you even bother helping us at all when I can do everything on my own?

Summary: If you want to help, please do help, we're grateful for it. If you don't want to help, please don't waste my time which is better spent on dealing with other patches from people who do want to help. TIA.

comment:6 Changed 13 years ago by arst

You have to realize that asking to get the bug report "exactly your way"
would cost me quite some time (and looking at the patch, it could be
resolved quickly).

1 - Hitting this wxWidgets bug costs time.
2 - Correcting it takes some time.
3 - Making a bug report takes some time.

(the bug report has been sleeping some days, so I don't have the
compiler output in front of me)

To get an error report from the linker (your way) I'd need to:

1 - Reboot the system
2 - Load a fairly big project
3 - Change the build mode to release (I'm usually not on debug config)
4 - Rebuild wxWidgets (VC++ throws away precompiled stuff when changing
build config, so this takes quite some time time)
5 - Paste linker error into bug report
6 - Then... (since my project is used in debug mode) I usually have to
rebuild that.

And then... reboot back to Linux if I was there.

This is a several hour procedure.

My point is that looking at a 15 line patch (with quite clear comments) that
solves a clear problem takes some 30 seconds. Then no need to ask for hours
of work from someone who has fixed a problem for you already.

I don't see a small patch file as a separate thing from a bug report.


comment:7 Changed 13 years ago by vadz

Contrary to what you seem to believe, I absolutely don't have wasting your time as a goal. I genuinely didn't understand which problem the patch was fixing, even after looking at it. Sorry for my poor capacities but I have to do with what I've got.

Besides, the exact linker message was not necessary, just saying that it fixed an undefined reference to wxGlobalSEInformation would have been quite enough and I don't believe that doing 'this' would have taken you several hours.

Finally, if you're doing cross-platform development and don't have VMWare (or any of the [free] alternatives, this just happens to be the one I'm happily using for many years), you're losing much more than several hours.

comment:8 Changed 13 years ago by arst

Maybe I could have read your initial posting a bit more flexibly (thinking about long compile times can throw me off). In my mind it was so obvious what the error was. Of course fixing the error is what it's about.

For vmWare and friends, yes, I use them, for some things. For full scale development (on my 1 GB machine) I find that it bogs down the machine too much, both Windows and Linux needs that 1 GB by themselves (Some Firefox windows and a couple of Visual Studio 9 pretty much uses that 1 GB). And VC++ compiler performance drops dead when starting to touch virtual memory. (So I need more memory).

Working on a file manager, I also find that I also need to be attentive to many small issues that only show themselves in every day use, things that will not come to the surface when testing software in a virtual machine.



Note: See TracTickets for help on using tickets.