Skip Menu |
 

This queue is for tickets about the Win32-OLE CPAN distribution.

Report information
The Basics
Id: 33485
Status: open
Priority: 0/
Queue: Win32-OLE

People
Owner: Nobody in particular
Requestors: Oliver.Koch [...] Linde-LE.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



CC: bug-PadWalker [...] rt.cpan.org
Subject: Problem with EPIC debugger and Win32::OLE
Date: Thu, 21 Feb 2008 12:45:19 +0100
To: bug-libwin32 [...] rt.cpan.org
From: Oliver.Koch [...] Linde-LE.com
Download (untitled) / with headers
text/plain 974b
Dear all, I've found a problem with the debugger of EPIC. When stepping over the Win32::OLE code of my little demo script (instead of using Run or Resume), the program output from Win32::OLE is different (and wrong). (See attached file: OLE-Excel_EPIC_Debug_Error.pl) For details of my configuration and outputs please look into the demo script. In the beginning I suspected the error is related to the Padwalker module, because you can avoid the wrong output by disabling the "Show local variables" option of the variables view in EPIC. But I already had some debug attempts with Robin Houston, who admirably tried to check whether the padwalker module needs a fixed. Please, follow this thread for details: http://rt.cpan.org/Ticket/Display.html?id=33211 Finally, it seems to me that the problem is more related to Win32::OLE and/or EPIC. Perhaps, you'd analyze the problem based on your background. Regards, Oliver P.S.: I post this report to the EPIC team, too.

Message body is not shown because sender requested not to inline it.

Subject: Fw: [rt.cpan.org #33485] Problem with EPIC debugger and Win32::OLE
Date: Fri, 22 Feb 2008 09:32:35 +0100
To: bug-libwin32 [...] rt.cpan.org
From: Oliver.Koch [...] Linde-LE.com
Download (untitled) / with headers
text/plain 4.5k
----- Forwarded by Oliver Koch/MUC/VA/Linde-VA on 22.02.2008 09:30 ----- Oliver Koch/MUC/VA/Linde -VA To bug-PadWalker@rt.cpan.org 22.02.2008 09:30 cc Subject Re: [rt.cpan.org #33211] Problem with Eclipse EPIC and 'Show Local Variables'(Document link: Oliver Koch) Dear Robin, "Robin Houston via RT" <bug-PadWalker@rt.cpan.org> wrote on 21.02.2008 19:04:18: Show quoted text
> > <URL: http://rt.cpan.org/Ticket/Display.html?id=33211 > > > Hi Oliver, > > I am quite interested in getting to the bottom of this, but there is > not much > hands-on debugging I can do, without a machine that can run > Win32::OLE. It may > well be that you do not have time to pursue this further, which I > understand.
I know, that you are fully committed to solve the issue and I'm very thankful for it. And I'm willing too to do my very best to help in finding the source of the problem. Show quoted text
> Unfortunately I don't have any specific idea of what the problem > might be. > I did wonder whether it could be related to the Win32::OLE module's > use of > tied variables. (Simply printing the value of a tied variable can invoke > arbitrary behaviour, of course.) However, I can't see any specific > way that > this would be a problem. Win32::OLE used tied hashes, and the EPIC code > does not seem to try and print the actual keys and values of a hash. > (However I don't completely understand how the EPIC system works, and > I must confess that I haven't used it myself, so perhaps I could be > mistaken on this point? I suspect not, from what I do understand of the > code.)
Neither do I, that's reason why I sent the issue to the EPIC (#1898659) and the Win32::OLE (#33485) team, too. I created a more general example making use of Excel's COM object instead of Visual Source Safe. I think someone from the Win32::OLE team should try to debug the example to get an idea, whether it's an internal problem, something special with the EPIC debugger or maybe with the padwalker module. Unfortunately, I neither have the knowledge nor the debug experience to do this own my own. Show quoted text
> It is not clear to me, from what you've said, whether the error code > is being > inappropriately set, or whether in fact the OLE call is failing, and > the error > response is correctly reflecting that.
I think, this is clear, because the OLE calls are executed correctly, but the return values from LastError() aren't accordingly. Show quoted text
> It seems unlikely to me that the LastError() method plays any part in > what > you're seeing, but I could be wrong. You could eliminate the possibility > by printing the error variable $Win32::OLE::LastError directly, > rather than > using the method.
I just tried this, but it didn't change anything. But I agree, that LastError() maybe just discovers, that there was something wrong (different) during the last OLE call. Show quoted text
> I think the changes you've made have eliminated the obvious ways that > the debugging could interfere with your program. What is happening must > therefore be something I haven't considered yet. If I were debugging > this > myself, the next thing I would try would be to recompile Win32::OLE with > the _DEBUG symbol defined, which will make it print lots of detailed > information about what it's doing. Comparing the output with and without > the debugger might yield some new clues.
I agree, that this should be the next step, but I don't feel instrumented/prepared to do this. So I think, it's more promising, that the Win32::OLE team have a look on his. Regards, Oliver
Subject: [rt.cpan.org #33485] Problem with EPIC debugger and Win32::OLE
Date: Mon, 9 Mar 2009 09:11:30 +0100
To: bug-libwin32 [...] rt.cpan.org
From: Oliver.Koch [...] Linde-LE.com
Download (untitled) / with headers
text/plain 1.9k
Dear Win32::OLE developers, There's an update from the EPIC developers related to this bug. It is assumed, that the problem lies within Win32::OLE. Please, confer the e-mail added below. So, I had again a look at the bug report #33485 at rt.cpan.org and found accidentally, that was added a very brief note: "JDB - Queue von libwin32 in Win32-OLE geändert " This messages looks like a bug fix, but I'm not sure, because the bug status is still on new. What does this message mean? Is the status really still on "new"? Should I do something? Regards, Oliver ----- Forwarded by Oliver Koch/MUC/VA/Linde-VA on 09.03.2009 09:00 ----- Jan Ploski <jpl@plosquare.co Show quoted text
m> To
Oliver.Koch@Linde-LE.com 08.03.2009 01:47 cc Subject Re: [ 1898659 ] Problem with EPIC debugger and Win32::OLE Dear Oliver, I examined your bug report and updated the ticket: http://sourceforge.net/tracker/index.php?func=detail&aid=1898659&group_id=75859&atid=545274 Regards, Jan Ploski
Subject: RE: [rt.cpan.org #33485] Problem with EPIC debugger and Win32::OLE
Date: Mon, 9 Mar 2009 11:51:32 -0700
To: <bug-Win32-OLE [...] rt.cpan.org>
From: "Jan Dubois" <jand [...] activestate.com>
Download (untitled) / with headers
text/plain 2.2k
On Mon, 09 Mar 2009, Oliver.Koch@Linde-LE.com via RT wrote: Show quoted text
> So, I had again a look at the bug report #33485 at rt.cpan.org and > found accidentally, that was added a very brief note: "JDB - Queue von > libwin32 in Win32-OLE geändert "
No, that was not a bug fix; it just means that all Win32::OLE related tickets are being copied to the libwin32@perl.org mailing list in addition to be sent to the maintainers. Show quoted text
> This messages looks like a bug fix, but I'm not sure, because the bug > status is still on new. What does this message mean? Is the status > really still on "new"? Should I do something?
I'm not sure there is anything that can be done about this, so I'm not sure that this really classifies as a bug, and not just as an unwelcome side-effect. It is similar to displaying the value of the expression ++$i without changing the value of $i. You have to save the state of $i, evaluate "++$i", record the result and then restore $i to its old value. Similarly accessing any object properties via Win32::OLE will change the value of Win32::OLE->LastError(). If you don't want that, then you have to save the value before accessing the properties, and restoring it afterwards: my $last_error = Win32::OLE->LastError(); # ... try to display the properties Win32::OLE->LastError($last_error); This is the activity the debugger would need to take every time it displays the value of a property w\of a Win32::OLE object if it doesn't want to destroy the value of Win32::OLE->LastError(). There is nothing Win32::OLE can do about this, as it doesn't know if the code is being called by the user program, or by the debugger. An OLE property access is not just a simple memory dereferencing operation; it will typically involve a remote procedure call to a different process, or possibly even to a remote machine, which can result in any number of errors. So a property access definitely needs to set Win32::OLE->LastError. Note that this problem is not unique to Win32::OLE->LastError() either; any tied hash or array implementation that has side effects will have similar problems when a debugger accesses its elements. I guess I should close this bug as a "known limitation", as any kind of work-around will have to go into the debugger anyways. Cheers, -Jan
Download (untitled) / with headers
text/plain 228b
As I wrote in my email reply, this problem is a "known limitation" and working as designed. The debugger will need to work around this as the module itself doesn't know when it is being invoked by a debugger, and when it isn't.
Subject: RE: [rt.cpan.org #33485] Problem with EPIC debugger and Win32::OLE
Date: Tue, 10 Mar 2009 08:02:12 +0100
To: bug-Win32-OLE [...] rt.cpan.org
From: Oliver.Koch [...] Linde-LE.com
Download (untitled) / with headers
text/plain 1.4k
Dear Jan, Thanks for the analysis. In general the explanation sounds reasonable. But to be honest I'm a little bit confused, because there is now a contradictory situation. From Padwalker module's point of view there couldn't be found a problem, from EPIC's point of view the problem is located in Win32::OLE, and from your's point of view the problem is within the debugger. Since I have not a deep enough insight into any of the three products, I feel, that I'm not capable to resolve this conflict. At first I'd like to ask, whether all parties have tested the same aspect of this incident? Secondly, I think, that the fastest and the most reliable way to fix this is, that you developers resolve this contradiction in direct communication: Jan Dubios <bug-Win32-OLE at rt.cpan.org> [rt.cpan.org #33485] Problem with EPIC debugger and Win32::OLE https://rt.cpan.org/Ticket/Display.html?id=33485 Jan Ploski <jpl at plosquare.com> [ 1898659 ] Problem with EPIC debugger and Win32::OLE http://sourceforge.net/tracker/index.php?func=detail&aid=1898659&group_id=75859&atid=545274 Robin Houston <bug-PadWalker at rt.cpan.org> [rt.cpan.org #33484] Problem with EPIC debugger and Win32::OLE http://rt.cpan.org/Ticket/Display.html?id=33484 [rt.cpan.org #33211] Problem with Eclipse EPIC and 'Show Local Variables' http://rt.cpan.org/Ticket/Display.html?id=33211 I hope, that this bring foward this incident to resolve without remaining questions. Kind regards, Oliver P.S.: I post this e-mail to all four treads.
Download (untitled) / with headers
text/plain 1.1k
On Mon Mar 09 15:17:46 2009, JDB wrote: Show quoted text
> As I wrote in my email reply, this problem is a "known limitation" and > working as designed. The debugger will need to work around this as the > module itself doesn't know when it is being invoked by a debugger, and > when it isn't.
I wasn't aware of this RT thread when posting my first assessment in the EPIC bug repository. Thanks to Oliver for pointing it out. You are correct that the problem now needs to be solved in the debugger, mostly because you have a published API and other clients who may already rely on this problematic behavior. From a design point of view, I think that your implementation is flawed, same goes for any other tied hash implementation with side effects. What looks like a memory access should be a memory access. Calls to (remote) procedures that may fail should look like calls to procedures. The semantics are quite different, as you correctly noted. I'll see what and whether anything can be done in EPIC to work around this Win32::OLE limitation. I suggest that the RT tickets here and for Padwalker should be closed and the issue further tracked on the EPIC side.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.