On 14.10.2013 22:18, Laurentius Purba wrote:
> Hello all,
>
> I am having core dump on Postgres 9.0.13 with the message "...was
> terminated by signal 10: Bus error...".
>
> So, I set a PID on the log file to capture specific PID that causing
> this crash. After, several crashes, I finally got the PID that causing
> this crash. But I am still not convinced that this process that causing
> this crash. That is the reason why I sent out this email, hoping anybody
> can help me or have had this experience before.
>
> Based on the PID on the log file, the crash happened while the
> application was trying to update a table's field with binary (PDF)
> content. The datatype of this field is TEXT.
Hi Laurentius,
wouldn't it be better to use BYTEA columns for binary content, not TEXT?
I'm not sure if that's a problem with PDF, but generally TEXT does not
allow some octet values (e.g. '\0').
The backtrace you've posted however lists a bunch of libxml functions at
the top, and in my experience libxml is not the best coded piece of
software. So I'd guess the problem is somewhere within libxml. What
version of libxml are you using?
Signal 10 usually means hardware error (but if the other jails are
running fine, it's unlikely) or about the same as SEGFAULT (i.e.
accessing invalid memory etc.).
What I don't understand is why the call ended in libxml when you're
dealing with PDF?
Is this reproducible? Does that happen with a particular PDF, or with
random PDF documents? Can you prepare a small self-contained test case?
regards
Tomas
