Segmentation fault #8
Comments
|
[comment redacted / moved to separate issue] |
|
It just works on my box :/ Is it possible that you provide a gdb backtrace for the segfaulting script?
|
|
[comment redacted / moved to separate issue] |
|
But in your very first snippet you said something about a segfault. Is that reproducable? |
|
That was from @nbdsp :) I just tried his code on my box when I saw him post and also got... failing.. results; though no segfault as I now see. Sorry. |
|
ahh :P |
|
@FROGGS Here the output of gdb: Reading symbols from /mnt/lib/perl6/rakudo/install/bin/moar...(no debugging symbols found)...done. Program received signal SIGSEGV, Segmentation fault. |
|
@nbdsp Can you paste your script again? |
|
Here the script verbatim: #!/usr/bin/env perl6 use v6; my $dbh = DBIish.connect('mysql', :host<my.host>, :port(3306), if !$dbh { say "Cannot connect to database"; exit } my $h = $dbh.perl; my $sth = $dbh.prepare("SELECT * FROM testdb.main WHERE id > 20"); say "Query created"; my $numrows = $sth.execute(); say "Query done! Rows:" ~ $numrows; my @arrayref = $sth.fetchrow(); say "Array fetched."; say @arrayref.elems; $sth.finish; |
|
Forgot to mention, maybe it is related to the problem, during installation of DBIish some tests failed and I installed it with --notests flag. (Is it needed to add some configuration to MySQL server before installing DBIish?) The errors were like this: |
|
Those are not test failures; they are diagnostic messages that indicate that tests aren't run, because the test DBs aren't available. If there were actual failures, I'd be interested in seeing them; if not, please install DBIish again, now that the tests are passing, and try again if you can reproduce the segfault. |
|
I reinstalled DBIish (with --notests) - no changes. Here is a full test output when installing with tests: |
|
If you want to run the tests, you need to do some prepwork and setup a test user/db. It's documented inside the test files in |
|
I added settings for tests and here the different part (from the previous snippet) of output: |
|
@nbdsp What type of operating system and architecture do you have? |
|
Linux 3.19.2-1-ARCH #1 SMP PREEMPT i686 GNU/Linux |
|
I have found a report about the same issue with segfault in 'I think it was a mismatch between an unsigned int and a 64bit signed int in one of those new fields I added." Maybe this info somehow can help. |
|
The difference between signed and unsigned integers sounds plausible, since iirc Rakudo and NativeCall didn't support the distinction at the time the mysql backend was written. |
|
So, DBIish cannot be used on Rakudo/Linux? |
|
Well, it worked for me (also on Linux), and in fact this is the very first report I've received that it's broken. |
|
I think I've ran into the same issue: gdb on first test file: gdb on second test file: |
|
Having glanced at MiniDBD code, I see that it uses deprecated Mysql functions mysql_query() and mysql_use_result(). Using mysql_real_query() solves the problem with the segfault. (mysql_real_query() accepts a string length as a parameter and doesn't call the strlen(), which caused the segfault. ) |
|
@nbdsp would you care to supply a patch? |
|
@zoffixznet I don't know much about your system, but does |
|
@moritz Well, I just began to study Perl 6, so I'm afraid I'm not qualified for that task. |
|
@moritz yes, it's a 32-bit system |
|
@nbdsp, @zoffixznet please try again with latest rakudo (which now supports unsigned integer types in native calls) and DBIish eb14b62? |
|
Seems like the problem is gone. Though one thing still is unclear: shouldn't the function execute() with "SELECT" query return the number of selected rows? The following code: Outputs 'Rows: -1', although the query seems to be performed OK and rows can be fetched with "fetchrow()" function. |
|
Strangely, the following code doesn't seem to work OK: It returns -1 and only two rows (from several dozens in DB) can be fetched with the fetchrow() or fetchall_arrayref(). But the following code with native calls works OK: |
|
Well, in case of mysql - 'execute()' seems should not return the number of selected rows (though why -1?). And 'fetchall_arrayref()' also works OK: in my previous snippet the code should be: So, the issue seems to be resolved. |
|
Since the segfault is fixed, I'm gonna close this. If you continue to have any other troubles, don't hesitate to open a new Issue. Thanks a lot for reporting! |
On Rakudo March 2015 there is a segmentation fault during fetching MySQL query results:
!/usr/bin/env perl6
use v6;
use DBIish;
my $dbh = DBIish.connect('mysql', :host<db.host>, :port(3306),
:database, :user, :$password);
my $sth = $dbh.prepare(q:to/STATEMENT/);
SELECT text
FROM main
WHERE id = '20'
STATEMENT
$sth.execute();
my $arrayref = $sth.fetchall_arrayref(); # <-- Segfault here
The same fault happens also with other fetching functions ( fetchrow(), etc )
EDIT:
$sth.execute() returns '-1', which obviously means that no rows was selected? But the query in the test code executes OK in MySql. Also '-1' is returned on any other selection query. Is query executed incorrectly in the sample code?
The text was updated successfully, but these errors were encountered: