Re: Segfault in threaded program after upgrade to DBI 1.620

2012-05-11 Thread Matthew Musgrove
I've retested with DBI 1.617 and DBI 1.618. Our program does not segfault
with either of them so it has to be something specific to the 1.620 changes.

Matt


On Thu, May 10, 2012 at 10:00 PM, Matthew Musgrove wrote:

> We have this threaded program that runs as a daemonized service and it's
> been happy for quite a while using DBI 1.616 and DBD::Oracle 1.30. Last
> week, I updated DBI to 1.620 and DBD::Oracle 1.44 and when I restarted the
> service, it segfaulted as soon as it created a new thread. I was pretty
> sure that it wasn't in DBD::Oracle because I had tested a prerelease of the
> new code and didn't have any problems with it. I reverted it back to DBI
> 1.616 and DBD::Oracle 1.30 and when I restarted the service, it was happy
> again. Next I updated DBI to 1.620 and left DBD::Oracle alone. Again, it
> segfaulted as soon as it created a new thread. It isn't my code so there
> could be a bug or three lurking in there waiting to attack but as I said,
> it's been working just fine. The only change was to DBI. I reverted DBI
> back to 1.616 and decided to wait (you know, to see if anyone would report
> anything).
>
> Today, I had a little free time and decided to try it again. It took some
> coaxing but I finally got it create a core dump (after setting
> DAEMON_COREFILE_LIMIT="
> unlimited"). I loaded the core dump in gdb and did a backtrace. It looks
> like it segfaults in dbi_ima_dup. Unfortunately, this perl didn't have
> debugging enabled. I compiled a new copy of perl (same version and I think
> the same flags except with debugging), installed the same modules for it
> and created another core dump. I logged 'backtrace', 'info registers' and
> 'thread apply all backtrace' to separate files. This was my first time
> using gdb so that was interesting. I don't really know what sort of
> information you need so... yeah.
>
> I'm attaching output from perl -V (from both copies of perl) and 'info
> registers'. I'll send a reply with the backtrace log next.
>
> What other information do I need to provide? Does anyone have any tips or
> pointers on how I can debug this further?
>
> Matt
>


Re: dbd-anydata v0.09 on windows - INSERT doesnt add new records

2012-05-11 Thread Jens Rehsack
On 11.05.2012 02:07, Greg Aiken wrote:
> dear jeff and jens,
> 
> i found your wonderful dbd-anydata module and installed it to my windows
> activeperl 5.8.8 build 820 environment (on Windows XP 32 bit)

Probably you should install a more recent version of DBD::AnyData.
As I can see in CPAN (http://search.cpan.org/dist/DBD-AnyData/),
DBD-AnyData-0.110 is the current version.

Without further information about the used DBI version, used
SQL::Statement version etc. pp., I can not even guess where
your problems comes from.

> i am able to use it to READ data from a 'Tab' delimited file.
> i have followed, almost verbatim, your sample code to INSERT new records
> into such a file - but i can not get this to work.
> 
> there are 3 different code fragment attempts ive made.  when each of
> these three code blocks run (one at a time obviously), in all cases the
> return code for the execute (or do) statement is 1 (true).  yet none of
> these actually results in a new record being added to the file
> 'oldfile.txt'.  ive attached oldfile.txt as a zip file so you can see
> its contents.  its a simple 2 line ascii file - record 1 is the field
> names, record 2 is a dummy data line.
> 
> if you can possibly figure out what i am doing wrong, i'd be greatly
> indebted as i can see using your module frequently if i can get it to
> output data.  

Even if I don't like to loose happy users, for the recorded simple use
it's probably reasonable to use DBD::CSV. Don't bite on "comma" - the
separator is freely configurable.

Further: I'm sure, DBD::AnyData has a test which proves whether
inserting new rows will succeed or not. If not (I didn't prove), it
would be nice if you add such a test case (steal it from DBD::CSV,
DBD::DBM or simply SQL::Statement).

If you can send the test output (including the test, if it needs to be
added), it'll be more easy for us to help you.

Thanks for helping to improve DBD::AnyData. Please CC dbi-users@ to
allow the community to help you.

Best regards,
Jens

> sincerely yours,
> 
> greg aiken
> 
> 
> 
> use DBI;
> use DBD::AnyData;
> 
> my $dbh = DBI->connect('dbi:AnyData(RaiseError=>1):');
> 
> 
> #i am trying to insert new record to an existing tab delimited file
> #'oldfile.txt' is an ascii encoded two line file:
> #FIELD1\tFIELD2\n
> #abc\tdef\n
> 
> $dbh->func('insertnewrecstooldfile', 'Tab', 'oldfile.txt', 'ad_import');
> 
> 
> 
> #test 1   - attempt using DO with hard-coded 'values'
> 
> #$return1 = $dbh->do("INSERT INTO insertnewrecstooldfile (FIELD1,FIELD2)
> VALUES ('ghi', 'jkl')");
> #print "return1 = $return1\n";
> #$dbh->disconnect;
> #exit;
> 
> #result: returns 1, but the file does NOT contain the new record!
> 
> 
> 
> #test 2   - next level of indirection, using scalar values in the sql
> command
> 
> #$value1  = 'mno';
> #$value2  = 'pqr';
> #$sql2= qq{ INSERT INTO insertnewrecstooldfile (FIELD1,FIELD2)
> VALUES ('$value1', '$value2') };
> #$return2 = $dbh->do($sql2);
> #print "return2 = $return2\n";
> #$dbh->disconnect;
> #exit;
> 
> #result: returns 1, but the file does NOT contain the new record!
> 
> 
> 
> #test 3  - to pass in vars
> #by way of preparing placeholders for values, then execute
> 
> #$value1  = 'stu';
> #$value2  = 'vwx';
> #$sql3= qq{  INSERT INTO insertnewrecstooldfile (FIELD1,FIELD2)
> VALUES (?,?) };
> #$sth3= $dbh->prepare($sql3);
> #$return3 = $sth3->execute($value1, $value2);
> #print "return3 = $return3\n";
> #$dbh->disconnect;
> #exit;
> 
> #result: returns 1, but the file does NOT contain the new record!
>