RE: core dump in mysql_bind_param (versions 4.1.1-alpha, 5.0.0-al pha, 4.1.2-alpha-nightly)
am 29.04.2004 14:05:54 von Kevin CowleyDean
I've now found the problem, stmt was NULL after
if ((stmt=mysql_prepare(conn,query, strlen(query))==NULL))
{
fprintf(stderr,
"mysql_stmt_prepare error with \"%s\": %s",
query, mysql_stmt_error(stmt));
return EXIT_SQL_FAIL;
}
but it wasn't printing the error message because the return from
mysql_prepare was actually non null.
I now have a related question on performance
Why are pre-compiled queries 50% slower to execute than parsed queries?
Based on the following
"INSERT INTO ssa_keys(urn,key_address,addr_part1,addr_part2,postcode)
Values(1,'8charstr','Part 1 of an address','part 2 of an
address','postcode')"
and
"INSERT INTO ssa_keys (urn,key_address,addr_part1,addr_part2,postcode)
Values(?,?,?,?,?)"
and inserting 24000 rows
The parsed query executes in 7 secs with a mean insert time of 277uS whilst
the compiled query (just the execute time - not including the prepare/bind
times) executes in 12 secs with a mean insert time of 455uS.
Each parsed query is different so the query string is rebuilt before being
passed to mysql_real_query(), whilst with the compiled query only the values
in the bound buffers are changed prior to each call to mysql_stmt_execute().
Why are pre-compiled queries 50% slower to execute than parsed queries?
Kevin Cowley
R&D
Tel: 0118 902 9099 (direct line)
Email: kevin.cowley@alchemetrics.co.uk
Web: http://www.alchemetrics.co.uk
-----Original Message-----
From: Kevin Cowley
Sent: 28 April 2004 19:35
To: 'Dean Ellis'
Cc: 'Bugs@lists.mysql.com'
Subject: RE: core dump in mysql_bind_param (versions 4.1.1-alpha,
5.0.0-alpha, 4.1.2-alpha-nightly)
Dean
Comments embedded below in [KC ]
Kevin Cowley
R&D
Tel: 0118 902 9099 (direct line)
Email: kevin.cowley@alchemetrics.co.uk
Web: http://www.alchemetrics.co.uk
-----Original Message-----
From: Dean Ellis [mailto:dean@mysql.com]
Sent: 28 April 2004 18:10
To: Kevin Cowley
Cc: 'Bugs@lists.mysql.com'
Subject: Re: core dump in mysql_bind_param (versions 4.1.1-alpha,
5.0.0-alpha, 4.1.2-alpha-nightly)
************************************************************ **************************
ALCHEMETRICS LIMITED (ALCHEMETRICS)
Mulberry Park, Fishponds Road, Wokingham, Berkshire, RG41 2GX
Tel: +44 (0) 118 902 9000 Fax: +44 (0) 118 902 9001
This e-mail is confidential and is intended for the use of the addressee only.
If you are not the intended recipient, you are hereby notified that you must
not use, copy, disclose, otherwise disseminate or take any action based on
this e-mail or any information herein.
If you receive this transmission in error, please notify the sender
immediately by reply e-mail or by using the contact details above and then
delete this e-mail.
Please note that e-mail may be susceptible to data corruption, interception
and unauthorised amendment. Alchemetrics does not accept any liability for
any such corruption, interception, amendment or the consequences thereof.
************************************************************ **************************
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kevin,
> Since I've got no response elsewhere then I'll try the bugs list I'm
> getting a core dump in mysql_bind_params which I need help in
> identifying why
Please send a complete test case; it may be that the problem is actually
outside the code block you provided, so having the full case will make
identifying that much easier.
[KC -
I've stepped through the code with a debugger and as soon as it calls
mysql_bind_params you get a segv error.
All of the arrays/variables have valid addresses so all I can conclude is
that it's missing something I haven't set up or it doesn't like one of the
variable types- my betting is on the key_address field, which is why I sent
you the table description as well.
The only stuff that is 'new' as far as this code is concerned is the
bind_vars array and the is_null variables. All the rest works perfectly
happily with a parsed query built using sprintf() and the relevant type for
each variable type.
What we're trying to measure/determine is how much quicker a compiled query
Is; when I can get it to do something other than core dump :-)
]
> The manual is no use as the 4.1.1 API actual quotes the (as yet)
> unimplemented 5.0.0 interface which is not what is currently in the
> 4.1.1-alpha 4.1.2-apha-nightly or 5.0.0-alpha sources.
The manual refers to the current 4.1.2 C API. A recent snapshot (and
the BitKeeper repository) would reflect this as well. If you mean
something else, please let me know.
[ KC - begin
I mean that, in the version available on the documentation page that
indicates it should be for 4.1.1 - which is actually labeled 5.0.0-alpha
-there are massive inconsistencies between the code examples and what I've
had to implement to get it to work.
For example the execute steps according to the 4.1.1 manual should be
stmt=mysql_stmt_init();
mysql_stmt_prepare(conn,query);
mysql_stmt_bind_param(stmt,bind_vars);
mysql_stmt_execute(stmt);
rather than
stmt=mysql_prepare(conn,query,strlen(query);
mysql_bind_params(stmt,bind_vars);
This is what makes me think there's some underlying problem I might not be
aware of.
end KC]
Best regards,
- --
Dean Ellis, Support Engineer & Software Developer
MySQL AB, www.mysql.com
Are you MySQL certified? http://www.mysql.com/certification
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFAj+VRAebV/bGJ5NERAlFqAJ0fAk+sut0r3Qvg/fdX2QyHdrImhwCf TDq1
y0/oDUKt4zXSUHeNaEN6dRk=
=cccd
-----END PGP SIGNATURE-----
--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org