Experimental Physics and
Industrial Control System

"Koennecke Mark \(PSI\) via Tech-talk" <[email protected]> · Thu, 15 Aug 2019 09:42:03 +0000

Hi,

thanks for the advice. Recompiling the code with win32-x86-debug solved the pointer corruption problem. 
Now I have another issue: my stack gets corrupted: Runtime error 2 or runtime error 1. This error does not 
occur if I comment away all calls into the FlexMotion library from NI. I only have binaries for 
that vendor supplied library. Is there anything that can be done in this situation? Help from the vendor 
is not available as the library is EOL. 

I checked all my calls into the library for properly typed parameters; this is not the issue.

Do I have to give up on tis one?

Regards,

    Mark Koennecke

> Am 01.08.2019 um 12:30 schrieb Freddie Akeroyd - UKRI STFC <[email protected]>:
> 
> Hi Mark,
> 
> You could set the various USR_* macros to add debug flags, but for something like debugging where you generally want the same set of flags applied consistently everywhere it is easiest to use the  win32-x86-debug  EPICS_HOST_ARCH  which also has the advantage that debug built binaries will be put in a different directory to non-debug ones so there is less change of them being accidentally linked together. It is not necessarily a problem if you do not have the source for a library you make use of to be able to rebuild it debug, but if the library returns memory or file pointers that it expects you to free() / fclose() then you will likely get issues mixing debug built code with this library. Worse case you may need to temporarily introduce a memory/resource leak to enable you to debug elsewhere in the code.
> 
> Regards,
> 
> Freddie  
> 
> -----Original Message-----
> From: Koennecke Mark (PSI) <[email protected]> 
> Sent: 01 August 2019 10:13
> To: Akeroyd, Freddie (STFC,RAL,ISIS) <[email protected]>
> Cc: Mark Rivers <[email protected]>; [email protected]
> Subject: Re: Pointer corruption on Windows
> 
> Hi Freddie, Mark,
> 
> 
>> Am 31.07.2019 um 19:53 schrieb Freddie Akeroyd - UKRI STFC <[email protected]>:
>> 
>> Sorry, forgot to CC: tech-talk
>> 
>>>> 
>>>> Hi Mark
>>>> 
>>>> What is your EPICS_HOST_ARCH set to? I wonder if pollEventId_ has got corrupt, are you able to step into the epicsEventSignal() or epicsEventWaitWithTimeout() function? 
>>>> Ultimately you will get to osdEvent.c in epics base where there is a 
>>>> HANDLE object inside the structure and you could see if that looks valid. I note that  pollEventId_ is next to a pAxes_ pointer in the controller header, so maybe there is an overwrite being caused if it turns out pollEventId_ is corrupt?
>>>> 
>> 
>>> Thanks for the quick response. EPICS_HOST_ARCH win32-x86. The FlexMotion library is only available for 32 bit, not 64. 
>>> I checked some more:
>> 
>>> - Had a breakpoint in the my constructor. Jotted down the value the 
>>> this pointer and the one from pollEventId at the end of the  constructor of my asynMotorConttroller derives class.
>>> - Set a breakpoint in the poller thread function of asynMotorController. All pointers in a happy state. At this stage all motors had been 
>>> created. I would expect problems here already when pAxes had overrun.  With the call to  epicsEventSignal()   everything goes wrong. 
>>> In order to debug into epicsEventSignal() I need to recompile EPICS base with debug support.
>> 
>> Sorry, I missed the "my" in front of "this" and thought that pollEventId was corrupt rather than "this". It would be worth compiling everything involved with an EPICS_HOST_ARCH  of win32-x86-debug as that gives much more useful debugger information; also you can sometimes get issues on Windows with mixing release and debug code as the debug and non-debug C libraries keep different heap lists so if memory is allocated by one library and freed by another unpredictable things can happen. Was the EPICS base you are currently using originally built with the same compiler you used for building asyn and motor?
>> 
> 
> Both my classes this pointer and the one from pollEventID get corrupted. 
> 
> All base, motor and asyn and my stuff were compiled with the same compiler. But base has no debug symbols in it. I tried to get a debug build by setting USR_CFLAGS but from your post I collect that the right way to do this is to set EPICS_HOST_ARCH to win32-x86-debug. The USR_CFLAGS thing was something I learned  on the WWW. Windows keeping different heap lists is weird. I do not have the source for all the standard libraries to compile with debug symbols… 
> 
> When I am back from holidays I will give it a fresh try with win32-x86-debug all over and more recent version of asyn and motor. And I remove the USR_* flags.
> 
> Regards,
> 
>     Mark Koennecke
> 
> 
> 
>> Regards,
>> 
>> Freddie
>> 
>> 
>> -----Original Message-----
>> From: [email protected] <[email protected]> On 
>> Behalf Of Mark Rivers via Tech-talk
>> Sent: 31 July 2019 17:20
>> To: Koennecke Mark (PSI) <[email protected]>
>> Cc: [email protected]
>> Subject: Re: Pointer corruption on Windows
>> 
>> Hi Mark,
>> 
>> 
>> asyn 4-25 is almost 5 years old. Could you try updating to a more recent version?
>> 
>> 
>> Mark
>> 
>> 
>> 
>> ________________________________
>> From: [email protected] <[email protected]> on 
>> behalf of Koennecke Mark (PSI) via Tech-talk <[email protected]>
>> Sent: Wednesday, July 31, 2019 2:41 AM
>> To: [email protected]
>> Subject: Pointer corruption on Windows
>> 
>> Hi,
>> 
>> I am trying to write a motor record driver for the PXI7344 motor controller from National Instruments and I am experiencing a weird pointer corruption problem.
>> First the environment:
>> 
>> - Windows 10, PSI computer security wants that
>> - MS Visual Studio 2010, I have to interface with the NI FlexMotion 
>> library which is EOL and from  this time
>> - base-3-14-12
>> - asyn4-25
>> - motorR6-9
>> 
>> I am using the asynMotorController. What I see in my debugger is that everything is fine with my pointer until epicsEventSignal(pollEventId_) is called in asynMotorController::wakeupPoller().
>> After that call my this pointer is corrupted and everything goes 
>> downhill from then. I tried to override wakeupPoller() to an empty 
>> method in order to get more information but then I get the pointer 
>> corruption on the call to  epicsEventWaitWithTimeout(pollEventId_, 
>> timeout) in
>> asynMotorController::asynMotorPoller()
>> 
>> Any ideas what could be wrong here?
>> 
>> Best Regards,
>> 
>>    Mark Koennecke
>> 
>> 
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System