|
Google will find it for you.
|
|
|
|
|
Hi,
This is not a c++ question. Interesting that you created this account specifically for asking this single question on a c++ forum.
What I find more interesting is that the linguistic syntax you are using such as "which include", "generated previously" and preposition usage such as "within" and the overall sentence length[^] strongly imply a native English speaker and not someone from the "Russian Federation" as your profile indicates.
Best Wishes,
-David Delaune
|
|
|
|
|
I tried to ask a question in a simple way, as is required by the rules. If the question is not in the appropriate category, I would like to know where to post it.
Vlad
Volgograd, Russia
|
|
|
|
|
A checksum is trivial functionality and was by the first reference I found, created in 1961.
There are variations but those are not relevant unless you have specific requirements.
Other than that libraries that might provide that functionality, especially now, would only (or should only) be adding management functionality - such as apply it to an entire directory.
So if you want to look for something 'better' you must first determine what, besides the checksum itself, that you need. Then find the libraries that meet those needs.
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
ForNow wrote: BTW wparam is a pointer from tcp/ip message/buffer and lparam is the length
Is this message sent or posted?
|
|
|
|
|
this is the code that is causing the exception
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
::PostMessage(thisocket->callwnd,thisocket->msg,(WPARAM) nRead,(LPARAM)sockbuffer.GetBuffer(0));
|
|
|
|
|
ForNow wrote: The code is invoked from a postmessage I.E
::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
|
|
|
|
|
|
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
|
|
|
|
|
That wasn't it
I think its something with the storage allocation .. the new
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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!
Bram van Kampen
|
|
|
|
|
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:
for(int i=0;i<A;i++){Foo(i);}
worked in Debug, but caused an exception in Retail.
The Work around was simple:
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,
Bram van Kampen
modified 30-Jun-17 18:58pm.
|
|
|
|
|
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.
|
|
|
|
|
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.
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 !~
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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
Poor Skype and an industry we won't talk about
In vino veritas
modified 28-Jun-17 3:22am.
|
|
|
|
|
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
|
|
|
|
|
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?
|
|
|
|
|
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
|
|
|
|