On Sat, Oct 18, 2008 at 15:20, Andrej van der Zee
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> I did not find a solution, I just stopped using prepared statements
> altogether. But I tried to isolate the problem just now, and found somehow
> that I cannot use FLOAT in prepared statement somehow (when I tried INT
> columns it even segfaults). Below the source code of a mini-module to
> illustrate this. This is the table I created in MySQL:
>
> CREATE TABLE simple_table (duration FLOAT NOT NULL) ENGINE=INNODEDB;
>
> And this is what appears in the MySQL log:
>
> Prepare INSERT INTO simple_table (duration) VALUES (?)
> Execute INSERT INTO simple_table (duration) VALUES ('')
>
> If you want to reproduce it, dont forget to put this in httpd.conf:
> LoadModule prep_stmt_module modules/mod_prep_stmt.so
> PrepStmt on
Hello,
I have not reproduced it, it's Saturday :-). I have never worked with
mod_dbd but I might have a clue though, although I am not sure.
You call ap_dbd_prepare from prep_stmt_config_set_prep_stmt_on. This
function is called during the conf parsing phase when there are no
apache children processes. cmd->server refers to the server structure
of the root apache process (the parent of all future apache children).
Then the apr_dbd_pvquery is called from an apache child process, in
which the server structure is not the same as the one you passed to
ap_dbd_prepare. As I have never worked with mod_dbd, I do not know if
this can cause a crash. If your mini-module is inspired from a
text-book or some working example, then my hunch is wrong.
Try the following: Leave cfg->prep_stmt_on = flag but move the
ap_dbd_prepare from the config hook to the child_init hook.
S
