On 9-12-2014 21:42, Aldo Caruso aldo.caruso@...
[firebird-support] wrote:

> I'm inserting records from PHP / Apache / Ubuntu in a Firebird
> table. This table has an integer non null field, and a before insert
> trigger which takes care of setting it to the next integer value in case
> the user attempts to set this field to null.
>
> If this field is set to any integer from PHP there is no problem.
>
> On the other hand, if it is set to null ( lefting to the trigger
> the task of assigning it ) any of the following behaviours happens
> (randomly)
>
> 1) A -804 error is shown in the apache log, with the message: "Dynamic
> SQL Error SQL error code = -804 Incorrect values within SQLDA structure"

Error numbers are not really helpful (eg -804 is 10 different errors),
it is better to provide the specific error code (which for this error
message is 335544713 (or isc_dsql_sqlda_value_err).

> 2) The Apache sub process is aborted, with the log message: "child pid
> NNNN exit signal Segmentation fault (11)"
>
> 3) A random integer is assigned to the field. This behaviour is by far
> less frequent, but happened a couple of times.

The problems you describe above are possibly caused by memory corruption
issues. It sounds like you or an intermediate layer is incorrectly
reading from or writing values into an XSQLDA (the struct used for
getting information into and out of Firebird), overwriting other memory
areas or reading (or causing Firebird to read) beyond process memory.

As you mention the field is NOT NULL, then most likely you (or the
intermediate layer) thinks it is possible to set a non-nullable XSQLVAR
to NULL without setting the sqltype to nullable. I have been bitten by
that problem myself once in the native sub-protocol in Jaybird (see
http://tracker.firebirdsql.org/browse/JDBC-271 and
http://tracker.firebirdsql.org/browse/CORE-3913).

The problem might be that fbclient does not check the null-indicator if
the sqltype is not-nullable, so it will attempt to read the sqldata
field that is either set to null, or worse pointing to a random memory
location. Another cause could be the reverse: the type has been made
nullable, but the sqlind value hasn't been set with similar results.

As I have no idea about the PHP side of things I can only guess about
workarounds, etc.

Mark
--
Mark Rotteveel