C / C++ / MFC

28-Jun-17 4:40

Hi
I'm getting a heap corruption error while debugging one
Of my message handling routines
It is on exit from the routine which lead me to think it's something with the stack or local variables
However I have not declared any local variables it's just parameters wparam and lparam
I can try to wrap the code in a try and catch I guess CMemoryException
I don't see any class members for CMemoryException Like line numbers ( line which caused the exception)
BTW wparam is a pointer from tcp/ip message/buffer and lparam is the length
Which I memcpy after doing a new in the routine
I am running 64 bit code

Thanks

Randor 28-Jun-17 5:11

Randor

28-Jun-17 5:11

Hey,

If you spend a few minutes to setup GFlags... you should quickly find the source of the heap corruption.

Where to get GFlags[^]

This is a very powerful tool... and you will become a much better engineer if you learn how to use the Windows debugging tools. Note that GFlags is not just for kernelmode... you can enable per-process heap monitoring in usermode processes:

Detecting Heap Corruption Using GFlags and Dumps[^]

Best Wishes,
-David Delaune

ForNow28-Jun-17 15:45

28-Jun-17 15:45

I tried it the Dialog Version of flags and this this time there was not a exception break

however I knew there is a problem because my stream in code didn't work meaning it didn't show

the text , typically when that happens there are some very subtle storage overlays or memory

exceptions as you mentioned when running in debug mode they sometimes show and sometimes

don't

So I just started taking my code apart removing all the control just having the rich edit

and the text was displayed

I'll put the code for the control back one at a time

until I find the exception

thanks

Victor Nijegorodov29-Jun-17 8:33

Victor Nijegorodov

29-Jun-17 8:33

ForNow wrote:
BTW wparam is a pointer from tcp/ip message/buffer and lparam is the length

Is this message sent or posted?

ForNow29-Jun-17 10:13

29-Jun-17 10:13

this is the code that is causing the exception

C++

LRESULT CprogDebug::GET_ZOS_STORAGE(WPARAM mywparam, LPARAM mylparam)
{
    
    
    mystorage[I]->len = mywparam;
    mystorage[I]->buffers = new char[mystorage[I]->len];
    memcpy((void *)mystorage[I]->buffers, (void *)mylparam, mystorage[I]->len);
    mystorage[I]->casid = as_id;
        mystorage[I]->Create(IDD_DIALOG6, NULL);
	
	return TRUE;
}

The code is invoked from a postmessage I.E

C++

::PostMessage(thisocket->callwnd,thisocket->msg,(WPARAM) nRead,(LPARAM)sockbuffer.GetBuffer(0));

Victor Nijegorodov29-Jun-17 10:26

Victor Nijegorodov

29-Jun-17 10:26

ForNow wrote:
The code is invoked from a postmessage I.E

C++
::PostMessage(thisocket->callwnd,thisocket->msg,(WPARAM) nRead,(LPARAM)sockbuffer.GetBuffer(0));

I guess that in a time the message is handled in your main thread the variable sockbuffer might go out of scope. The result - the memory exception.
Is this message is posted from the other (socket) thread?
Anyway, check out this great J.Newcomer essay: WorkerThreads

ForNow29-Jun-17 10:49

29-Jun-17 10:49

yes it is thanks

Randor 29-Jun-17 10:52

Randor

29-Jun-17 10:52

ForNow wrote:
::PostMessage(thisocket->callwnd,thisocket->msg,(WPARAM) nRead,(LPARAM)sockbuffer.GetBuffer(0));

As Victor is implying... change this to use SendMessage [^] and see if your problem goes away.

Best Wishes,
-David Delaune

ForNow29-Jun-17 15:51

29-Jun-17 15:51

That wasn't it

I think its something with the storage allocation .. the new

David Crow29-Jun-17 17:37

David Crow

29-Jun-17 17:37

What is the value of mystorage[I]->len?

Is mystorage[I]->buffers non-null before calling memcpy()?

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles

ForNow30-Jun-17 2:17

30-Jun-17 2:17

mystorage[I}->len has the right value, I didn't check mystorage[I]->buffers for non NULL

but it has an address and the right data after the memcpy

However as Victor pointed out sockbuffer is from a different thread

I knew something was wrong when my rich edit didn't get populated running under the

debugger subtle storage overlays don't cause exceptions

I have a question if invoke exception handlers ( and I have to read up on it)

will it catch the exceptions that the VS debugger bypasses

Thanks

thanks

Bram van Kampen30-Jun-17 13:14

Bram van Kampen

30-Jun-17 13:14

Ah We are getting Somewhere!
At least some code.

On the Off Chance of asking a stupid question, I do not see any declarations for the Index 'I', nor for the class 'mystorage', nor for the object 'as_id'.

Are you working on a PC or an IBM Main Frame, with z/OS Operating System.

I am getting Confused! Smile | :)

Bram van Kampen

UDP Sockets and Windows 10

Bram van Kampen30-Jun-17 12:51

Bram van Kampen

30-Jun-17 12:51

Well,

You have another post about the failures of optimizers. Do those threads relate to the same problem? (or even the same problem?)

I understand that you are in a state of desperation. Believe me, I've been there myself, many times and more. When all other options fail, you are left with nothing else left to blame, but the compiler. I must say, I use a Windows NT version of the Development Environment hailing back to 1998, and, that has indeed a few issues, which I have now documented and hence avoid.
For Instance, Standard Code like:

C++

for(int i=0;i<A;i++){Foo(i);}

worked in Debug, but caused an exception in Retail.
The Work around was simple:

C++

int i; for(i=0;i<A;i++){ Foo(i);}

Be Realistic, anything drastically wrong with the MFC Compiler or MFC Libraries, would very soon have thrown up issues world wide.

I understand that your code runs flawless in the Debug version, but bails out in the retail version. The difference between the two builds are far bigger than the application of an optimisation process. For starters they link into different MFC Libraries.

Have you tried: Why Program works in debug but not release mode By Microsoft, or, Surviving the Release Version in our own Code Project Site.

There is something trivial wrong with your code, that your compiler can read and interpret without generating a syntax error, but which also does something quite different than what you intended it to do, and causes an exception to be thrown in release mode. The Debug mode tends to be more tolerant of (wittingly or unwittingly) doing 'Smart' things.

In order to allow us to help you, show us some (or Much) of the offending Code by attachment.
Regards, Smile | :)

Bram van Kampen

modified 30-Jun-17 18:58pm.

Rick York27-Jun-17 13:27

27-Jun-17 13:27

I have a program that works just fine in all versions of 32 and 64-bit windows except for 10. I have tracked down the cause of the problem to UDP sockets. I have not been able to make them work with W10. TCP sockets work fine but UDP sockets are giving me fits. This same code works without issue on my old W7 box so I am now working on it just so I can make progress.

Does anyone know of a fundamental issue with W10 and UDP sockets or is it just some setting somewhere they I need to correct?

modified 28-Jun-17 13:48pm.

Afzaal Ahmad Zeeshan27-Jun-17 13:44

Afzaal Ahmad Zeeshan

27-Jun-17 13:44

Rick York wrote:
This same code works without issue on my old W7 box so I am no working it just so I can make progress.

Which same code?

Secondly, Windows 10 supports UDP as well as TCP, the thing to note here would be, are you implementing UDP protocol properly? UDP is a very notorious protocol, as there are several handy things, that are missing in UDP — which TCP can brag about. I would personally believe, that you would need to double check the usage or implementation of UDP clients.

Since you have not shared anything (code, working sample, UDP helpers etc.), it is hard to consider what might be doing wrong. Smile | :)

Before you start, understand that since most of the times UDP packets are used for malicious purposes, Windows may prevent them from entering, so please read the following resources before you starting doing anything,

UDP Communication is blocked by the Windows Firewall rule in WSFC
c# - Problems with UDP in windows 10. UWP - Stack Overflow
windows 10 Version 1607 dropped udp packets with activated multicast

The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~

Rick York27-Jun-17 16:49

27-Jun-17 16:49

Thank you for the links. They gave me a couple of hints to look into. Interesting coincidence : these apps communicate with cameras also but they aren't GigE and this is not a multicast problem, it's all unicast. I did not include code because the same code on both ends (camera and PC) works fine in XP and W7 and fails only on W10. Wireshark shows a well-formed packet being sent to the right destination but there is no response. It seems like it may be a firewall issue. That's where I am going to look next.

Randor 27-Jun-17 20:27

Randor

27-Jun-17 20:27

Afzaal Ahmad Zeeshan wrote:
Before you start, understand that since most of the times UDP packets are used for malicious purposes, Windows may prevent them from entering, so please read the following resources before you starting doing anything,

Good luck browsing the internet without UDP ... DNS utilizes UDP as well as many Microsoft system services. It is false that Microsoft blocks or has special rules for UDP.

Best Wishes,
-David Delaune

leon de boer27-Jun-17 21:15

leon de boer

27-Jun-17 21:15

Live streaming would be severely limited without UDP you would have to buffer everything packet it up and deal with the TCP nak requests for resend from every user. There is no such thing as multicast on TCP it requires 1 to 1 handshaking. So do you really think your $50 webcam is going to be able to do that to thousands of users Smile | :)

Poor Skype and an industry we won't talk about Smile | :)

In vino veritas

modified 28-Jun-17 3:22am.

Randor 27-Jun-17 20:37

Randor

27-Jun-17 20:37

Hi,

Rick York wrote:
Does anyone know of a fundamental issue with W10 and UDP sockets or is it just some setting somewhere they I need to correct?

The high level functionality in the network stack of Windows 10 is basically the same as the network stack in previous Windows releases. Your problem is most likely due to some firewall restriction policy.

Btw, the obligatory "This is not a C++ question" applies here.

Best Wishes,
-David Delaune

Rick York28-Jun-17 6:59

28-Jun-17 6:59

This is the obligatory "where should it go then?" question.

The camera code is written in C. The PC app is C++ and MFC. I don't see a networking or Win10 category so where should it go?

Randor 28-Jun-17 7:53

Randor

28-Jun-17 7:53

Rick York wrote:
This is the obligatory "where should it go then?" question.

I would suggest the System Admin forum[^] as this is exactly the type of thing they do all day.

Some suggestions:

1.) Use wireshark to see if the packets are being sent. If you see the packets in wireshark... it means they are being physically sent down the wire. This also suggests that your problem is not the program... probably a router or hardware firewall issue.

2.) Bring the camera into your office and connect it directly to your workstation... without any switch or router in the middle. All Ethernet chipsets these days support auto-mdix and do not need a crossover cable. I'm showing my age here...

Best Wishes,
-David Delaune

jeron128-Jun-17 5:04

jeron1

28-Jun-17 5:04

What types (if any) of error codes are you seeing?

"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle

Rick York28-Jun-17 6:57