EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Pointer corruption on Windows
From: Freddie Akeroyd - UKRI STFC via Tech-talk <[email protected]>
To: "Koennecke Mark (PSI)" <[email protected]>
Cc: "[email protected]" <[email protected]>
Date: Thu, 1 Aug 2019 10:30:38 +0000
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
> 
> 


Replies:
Re: Pointer corruption on Windows Koennecke Mark (PSI) via Tech-talk
References:
Pointer corruption on Windows Koennecke Mark (PSI) via Tech-talk
Re: Pointer corruption on Windows Mark Rivers via Tech-talk
RE: Pointer corruption on Windows Freddie Akeroyd - UKRI STFC via Tech-talk
Re: Pointer corruption on Windows Koennecke Mark (PSI) via Tech-talk

Navigate by Date:
Prev: Re: Pointer corruption on Windows Koennecke Mark (PSI) via Tech-talk
Next: RE: [motorPIGCS2] can't turn on servo state of PI E-712 Allan Serra Braga Bugyi via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Pointer corruption on Windows Koennecke Mark (PSI) via Tech-talk
Next: Re: Pointer corruption on Windows Koennecke Mark (PSI) via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024 
ANJ, 15 Aug 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·