Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ Library : Other (not classified elsewhere) » Problem with dialogs
Problem with dialogs [message #47032] Mon, 14 November 2016 11:41 Go to next message
koldo is currently offline  koldo
Messages: 3398
Registered: August 2008
Senior Veteran
Lately (from weeks or few months) I am having problems with dialogs. Without any apparent reason and not always, they crash the program when closing them.

For example this function called from a THISBACK after clicking a button, may crash in the destructor:

void ScatterCtrl::DoProcessing() 
{
	ProcessingDlg(*this).Run(true);
}

It is also happening many times with FileSel.

It seems it happens when the dialog constructor is inside a function, like here:
void Function_called_by_a_THISBACK() {
	FileSel fs;
	// Do something
	// FileSel crashes in its destructor when going out of the function
}

Am I doing anything wrong?


Best regards
Iñaki
Re: Problem with dialogs [message #47038 is a reply to message #47032] Thu, 17 November 2016 23:52 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14108
Registered: November 2005
Ultimate Member
Please, some info. Is it trunk or 'classic'. What OS?

In trunk, I have not encountered anything like that. From what you write, it seems ok, maybe there are some special issue elsewhere?

Examples/reference crashing?

If yes, which ones?

If not, would it be possible to create some minimal example?
Re: Problem with dialogs [message #47039 is a reply to message #47038] Fri, 18 November 2016 08:29 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3398
Registered: August 2008
Senior Veteran
Sorry Mirek, this problem happens randomly.

System is Windows 7 64, and I always use latest trunk.

Problem seems to disappear when dialogs are declared inside TopWindow class or are global (inside a function).

However I will follow monitoring it. Thank you.


Best regards
Iñaki
Re: Problem with dialogs [message #47041 is a reply to message #47039] Fri, 18 November 2016 08:33 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14108
Registered: November 2005
Ultimate Member
MT involved?
Re: Problem with dialogs [message #47051 is a reply to message #47041] Mon, 21 November 2016 08:38 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3398
Registered: August 2008
Senior Veteran
mirek wrote on Fri, 18 November 2016 08:33
MT involved?
Yes, program is MT (multi threaded), although problematic dialogs do not use MT.


Best regards
Iñaki
Re: Problem with dialogs [message #47076 is a reply to message #47051] Tue, 29 November 2016 08:51 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3398
Registered: August 2008
Senior Veteran
This time the same error has appeared after calling an Exclamation().

Internally Exclamation() calls Prompt() that declares a PromptDlgWnd__ class that is destroyed when going out of Prompt() function.

The problem appears in the destructor.

index.php?t=getfile&id=5078&private=0
  • Attachment: Image.png
    (Size: 20.25KB, Downloaded 470 times)


Best regards
Iñaki
Re: Problem with dialogs [message #47077 is a reply to message #47076] Tue, 29 November 2016 10:05 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14108
Registered: November 2005
Ultimate Member
This looks like something has overwrote TopWindow instance data with garbage (icon and largeicon members). From the description, looks like stack frame overwrite.

Any chance you are using some C arrays in your code? Or pointers to stack objects?

int h[200];

h[x] = something;


Or maybe using some library that does?

All I can say now is that I have the same setup for my major apps (win, in both 32 and 64 bit modes), I am doing a lot of stack based dialogs and prompts and never met this issue before... I do not rule out U++ as culprit, but...

Mirek
Re: Problem with dialogs [message #47084 is a reply to message #47077] Wed, 30 November 2016 09:15 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3398
Registered: August 2008
Senior Veteran
Thank you Mirek, I understand. Stack overwriting could be the culprit.

Do you know if is there an easy way to check problems in the stack?


Best regards
Iñaki
Re: Problem with dialogs [message #47086 is a reply to message #47084] Wed, 30 November 2016 09:33 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14108
Registered: November 2005
Ultimate Member
koldo wrote on Wed, 30 November 2016 09:15
Thank you Mirek, I understand. Stack overwriting could be the culprit.

Do you know if is there an easy way to check problems in the stack?


No easy way. I guess there are compiler options (like /GS in MSC), but never really tried them.

You can try to check all '[' (in declaration) and 'Buffer' uses. That is where I would start...

Mirek
Re: Problem with dialogs [message #47087 is a reply to message #47084] Wed, 30 November 2016 10:37 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

koldo wrote on Wed, 30 November 2016 09:15
Thank you Mirek, I understand. Stack overwriting could be the culprit.

Do you know if is there an easy way to check problems in the stack?

Hi Koldo,

You can run the code in Valgrind Wink It is slow, but can help with all kinds of invalid memory access problems. There is also some limited support in TheIDE (at least on linux).

Best regards,
Honza
Re: Problem with dialogs [message #47089 is a reply to message #47087] Thu, 01 December 2016 09:03 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3398
Registered: August 2008
Senior Veteran
Thank you!

I will try both sides. Valgrind is only for Linux but there are other Windows counterparts.

The reason I imagine follows this sequence:
- A thread declares a C array
- A dialog is declared and opened
- The thread goes out of the bounds smashing dialog memory
- The dialog is closed and crashes in the destructor

This way, although both the thread and the dialog are unrelated, the thread smashes dialog memory.

It is curious that this only happens to very unrelated TopWindow subclasses. Maybe it is simply because TopWindow uses much memory and so the probability of being crashed is higher.


Best regards
Iñaki

[Updated on: Thu, 01 December 2016 09:03]

Report message to a moderator

Re: Problem with dialogs [message #47090 is a reply to message #47089] Thu, 01 December 2016 09:09 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14108
Registered: November 2005
Ultimate Member
koldo wrote on Thu, 01 December 2016 09:03
Thank you!

I will try both sides. Valgrind is only for Linux but there are other Windows counterparts.

The reason I imagine follows this sequence:
- A thread declares a C array
- A dialog is declared and opened
- The thread goes out of the bounds smashing dialog memory
- The dialog is closed and crashes in the destructor

This way, although both the thread and the dialog are unrelated, the thread smashes dialog memory.


Actually, this scenario is sort of less likely: Thread has own stack, so going out of bounds there is not going to break the dialog in GUI thread (of course, you can only have dialogs in main thread's stack, but I am sure you know that).

Quote:

It is curious that this only happens to very unrelated TopWindow subclasses. Maybe it is simply because TopWindow uses much memory and so the probability of being crashed is higher.


Well, this possibly might be a reason too - you are running out of stack. Usually it ends in different error but it is worth checking: Build with verbose and check there is /STACKSIZE:8000000 or bigger number in linker.
Re: Problem with dialogs [message #47092 is a reply to message #47090] Fri, 02 December 2016 08:54 Go to previous message
koldo is currently offline  koldo
Messages: 3398
Registered: August 2008
Senior Veteran
Uuups. Threads have their own stack!.

Linker has /STACK:20000000 (> 8000000)
The application is 32 bits. Exe. size in debug mode is 36 Mb.


Best regards
Iñaki
Previous Topic: Append line into LineEdit or DocEdit
Next Topic: RegEx Help
Goto Forum:
  


Current Time: Tue Nov 05 14:09:40 CET 2024

Total time taken to generate the page: 0.01803 seconds