If you retry, what makes you think the outcome will be any different? If you do it automatically, there's a good chance you'll end up in a retry loop. If you continue with the next instruction, well, it's not called undefined behavior for nothing. It's best to generate a stack trace to help you debug and fix the problem. I've written an article[^] about this.
Maybe I can better explain the problem. A lot of times I have code that works perfect in debug and then in release blows up
what I would like my SEH handler to do is debug break at the abend. not quite sure how to go about this. In my SEH I unwind the stack to get to the right place
I guess at that point I can Messagebox the line number and do a debugbrk ?
I've not done debug breaks out of code, so I can't help you there. If your code works in debug, but not in release, it's probably using uninitialized data. One issue that you could face is that, in a release build, the compiler may have optimized the code to the point where it's difficult to follow.
What I do in the SEH is map it to a POSIX signal (e.g. SIGABRT), raise that, catch it in the signal handler, and throw a C++ exception that my base Thread class will catch. The constructor for the exception captures the function call chain before the stack is unwound, and the chain then gets displayed in a log.
If you retry, what makes you think the outcome will be any different?
Just retrying blindly usually makes little sense. However, the handler may have taken steps to remedy the situation.
Say if you have this (instruction level) memory allocation mechanism, failing because no free block of the requested size was available. The handler could do a heap compaction, and if that fails to create a big enough free block, allocate more memory to the heap from a lower level mechanism, and then request the application to retry the allocation instruction.
Any handler trying to remedy a fault situation (whether at instruction level or higher software level) should keep track of the retries. If the same fault occurs repeatedly, retries should be reconsidered. I have seen several examples where such strategies were followed, e.g. in telephone switches where software modules where updated while the system was running: If an updated module caused a fault for the third time, the previous (and presumably stable) version was automatically reinstated.
(In some areas, computer network guys could learn a few things from the telecom guys! It is a pity that IP networks are pushing out traditional telecom networks before we got ourselves to pick up that knowledge before it is forgotten!)
That kind of retry is possible, but it's unusual. My background was also telecom switches, and we used pools of fixed-size blocks, each dedicated to a specific subsystem, instead of a heap. It was similar to what I describe in this article[^], in which an orphaned block gets recovered by a background garbage collector if it remains unclaimed by the application that allocated it.
I get eacces Return code when I try to open a file in my ftp folder I try to open it read only
Wondering a few things I created a while ago not sure it’s password protected ( don’t think so )
Or maybe I have to use FTP api to copy it or read it
Wondering if any one has had any experience with this
I think we need some more details. Can you access the folder to get a directory listing? Is this a local or remote folder? Do you have administrator access to the folder/file? Is this at a command prompts or in some application?
From a Windows MFC program
I have notify callback whenever the directory changes. I download via EZAFTPKA program Ftp api on z/os a binary file ( sysadata of a program this is like pdb in VS) after the notify file added I try to _sopen for read only
This may be a simple matter of Windows not trusting the source of the file. I know that sometimes when downloading files Windows will semi-quarantine them and you need to enable access manually. Take a look at the file itself and check the properties.
I´m try to get a communication between a process written in c++ and a process written in c#.
Each Processes have a RPC Server ans a RPC Client.
The following situation exists:
It´s possibel to start a correct RPC communication between 2 processen written in C++.
And it´s also possible to start a correctly RPC communication between 2 processes written in C#.
It´s not possible to start a correctly RPC communication between a process written in c++ and a process written in c#.
The interface is initialized with the "ncacn_ip_tcp" protocol.
The error accours in the function "NdrGetBuffer(,,)". This function is declared in "rpcndr.h".
The client use this function for getting a pointer from the RPC server to send the requiered datas.
I don´t no how shall I do now.
Is there anyting to setup in user settings?
Can someone help me?
Have someone also problems with RPC Server / Clients
Thank You very much.
thanks for the hint.
I´ve already scoured this page.
In my application the server and client works with "endpoint" definition
not with ports.
As I said.
Processes that are written in C ++ communicate with one another, as do the processes that are written in C #. This is not a problem.
No communication between processes written in C ++ and processes written in C #.
If someone has these problems in the same way, I would be happy to hear from you.