Re: Segmentation Fault
От | Christoph Haller |
---|---|
Тема | Re: Segmentation Fault |
Дата | |
Msg-id | 3E8C19B5.6050106@rodos.fzk.de обсуждение исходный текст |
Ответ на | Segmentation Fault ("Frankie Lam" <frankie@ucr.com.hk>) |
Список | pgsql-interfaces |
>> Oh, I'm so sorry....> I've made a stupid mistake... and this mistake is at the cost of 3 days> work.> The segmentationfault 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
В списке pgsql-interfaces по дате отправления: