Re: Segmentation Fault

>
> Oh, I'm so sorry....
> I've made a stupid mistake... and this mistake is at the cost of 3 days
> work.
> The segmentation fault is totally irrelevant to the time functions in
> previous thread.
>
Keep your head.
AFAICT segmentation faults are every C programmer's nightmare
and best known for hard to find. I know of people searching for
mistakes even longer and I've seen mistakes more stupid than yours.

>
> Here I have one more question, is there any debugging tools other
than GDB?
> I'm not quite used to it, debugging segmentation fault is really a
pain. :-(
>
I don't know of one. I'm using xdb on HP-UX, which is quite similar I
suppose.
I've found it useful when trying to track down, do not trace, but let it
simply run
within the debugger and then use the "down" command to find your code area.
There is also a function called memorymap(int show_stats) which often
detects
memory faults before the operating systems does.

> len =strlen(PQgetvalue(res, 0, i)) * 2 + 1; // <=========
Why not using PQgetlength(res, 0, i)?
> PQescapeString(tmp2, PQgetvalue(res, 0, i), len); // <=========
One last question:
Why are you using PQescapeString on PQgetvalue?

The doc says:
If you want to include strings that have been received from a source
that is not trustworthy (for example, because a random user entered
them), you cannot directly include them in SQL queries for security
reasons. Instead, you have to quote special characters that are
otherwise interpreted by the SQL parser.

So PQgetvalue is trustworthy. There should be no need to call
PQescapeString,
except you were using a binary cursor. But if you were using one, then why
would you want to escape the result instead of just using a normal cursor?

Regards, Christoph