Skip Menu |

This queue is for tickets about the Object-InsideOut CPAN distribution.

Report information
The Basics
Id: 58394
Status: resolved
Priority: 0/
Queue: Object-InsideOut

People
Owner: Nobody in particular
Requestors: travis.vickers [...] centrelink.gov.au
Cc:
AdminCc:

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



Subject: Object-InsideOut clashing with DBI [SEC=UNCLASSIFIED]
Date: Tue, 15 Jun 2010 16:31:18 +1000
To: bug-Object-InsideOut [...] rt.cpan.org
From: travis.vickers [...] centrelink.gov.au
Hi there, We have recently notices a problem with Object-InsideOut (OIO) clashing with DBI. It appease that making a DBI connection tries to destroy the OIO object. If we undefine the OIO object before we make the DBI connection it works fine. It also works fine if we only define the OIO object after the DBI connection. Here are some helpful details about our OS, perl version and the libraries we are using: Distribution name and version: Object::InsideOut version 3.54, DBI version 1.601 ($Revision: 10087 $). Perl version: v5.8.8 built for sun4-solaris-thread-multi OS Vendor & Version: SunOS nccfuz163 5.10 Generic_142900-04 sun4u sparc SUNW,Netra-T12 We have attached a simple example that is reproducing the error for us. Note: We replaced the database name, user name and password with 'generic' values. When the above sample script is run, we get the following output: $> ./test.pl USERNAME ERROR: Attempt to DESTROY object ID 1 of class Foo twice $> Thanks in advance. Travis Vickers ********************************************************************** IMPORTANT: This e-mail is intended for the use of the addressee and may contain information that is confidential, commercially valuable or subject to legal or parliamentary privilege. If you are not the intended recipient you are notified that any review, re-transmission, disclosure, use or dissemination of this communication is strictly prohibited by several Commonwealth Acts of Parliament. If you have received this communication in error please notify the sender immediately and delete all copies of this transmission together with any attachments. **********************************************************************

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

On Tue Jun 15 02:31:41 2010, travis.vickers@centrelink.gov.au wrote: Show quoted text
> We have recently notices a problem with Object-InsideOut (OIO) > clashing with DBI. > > When the above sample script is run, we get the following output: > $> ./test.pl > USERNAME > ERROR: Attempt to DESTROY object ID 1 of class Foo twice > $>
The problem is that DBI or whichever DBD module you're using is doing a 'require threads' in the background. I determined this from your example by connecting to an SQLite DB. I didn't get the error until I added 'require threads;' between the creation of the OIO object and the DBI calls. This is causing OIO to believe it's working in a potentially threaded application without the proper initialization. The OIO POD addresses this under THREAD SUPPORT: To use Object::InsideOut in a threaded application, you must put S<C<use threads;>> at the beginning of the application. (The use of S<C<require threads;>> after the program is running is not supported.) If object sharing is to be utilized, then S<C<use threads::shared;>> should follow. Of course, this is not an issue with your test code per se. It's really an issue with the DBI/DBD module. Regardless, there is a simple workaround. Just add 'use threads;' at the start of your application code and it should function properly. I'll add a note regarding this to the POD. Thanks for the bug report.
Subject: Re: [rt.cpan.org #58394] Object-InsideOut clashing with DBI [SEC=UNCLASSIFIED]
Date: Wed, 16 Jun 2010 11:17:25 +1000
To: bug-Object-InsideOut [...] rt.cpan.org
From: travis.vickers [...] centrelink.gov.au
Hi Jerry, Thanks for providing us with an easy work around and so quickly. Just had another read of the OIO doco and yes threads are mentioned in there... Guess this one falls back on us not reading the doco. Thanks for your time and patience. Travis Vickers From: "Jerry D. Hedden via RT" <bug-Object-InsideOut@rt.cpan.org> To: travis.vickers@centrelink.gov.au Date: 16/06/2010 01:19 AM Subject: [rt.cpan.org #58394] Object-InsideOut clashing with DBI [SEC=UNCLASSIFIED] <URL: https://rt.cpan.org/Ticket/Display.html?id=58394 > On Tue Jun 15 02:31:41 2010, travis.vickers@centrelink.gov.au wrote: Show quoted text
> We have recently notices a problem with Object-InsideOut (OIO) > clashing with DBI. > > When the above sample script is run, we get the following output: > $> ./test.pl > USERNAME > ERROR: Attempt to DESTROY object ID 1 of class Foo twice > $>
The problem is that DBI or whichever DBD module you're using is doing a 'require threads' in the background. I determined this from your example by connecting to an SQLite DB. I didn't get the error until I added 'require threads;' between the creation of the OIO object and the DBI calls. This is causing OIO to believe it's working in a potentially threaded application without the proper initialization. The OIO POD addresses this under THREAD SUPPORT: To use Object::InsideOut in a threaded application, you must put S<C<use threads;>> at the beginning of the application. (The use of S<C<require threads;>> after the program is running is not supported.) If object sharing is to be utilized, then S<C<use threads::shared;>> should follow. Of course, this is not an issue with your test code per se. It's really an issue with the DBI/DBD module. Regardless, there is a simple workaround. Just add 'use threads;' at the start of your application code and it should function properly. I'll add a note regarding this to the POD. Thanks for the bug report. ********************************************************************** IMPORTANT: This e-mail is intended for the use of the addressee and may contain information that is confidential, commercially valuable or subject to legal or parliamentary privilege. If you are not the intended recipient you are notified that any review, re-transmission, disclosure, use or dissemination of this communication is strictly prohibited by several Commonwealth Acts of Parliament. If you have received this communication in error please notify the sender immediately and delete all copies of this transmission together with any attachments. **********************************************************************