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
<2019>
2020
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
<2019>
2020
2021
2022
2023
2024
|