[BUGS] BUG #2246: Bad malloc interactions: ecpg, openssl
The following bug has been logged online: Bug reference: 2246 Logged by: Andy Klosterman Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.0 Operating system: Debian testing: Linux nc3 2.4.27-2-386 #1 Wed Nov 30 21:38:51 JST 2005 i686 GNU/Linux Description:Bad malloc interactions: ecpg, openssl Details: Before going into a full description and figuring out some example code for this situation, I'm fishing for interesting in tracking it down and fixing it (or not). On a program that I (pre-)compile with ecpg and connect to a remote Postgres instance over an SSL connection (as set up in pg_hba.conf with appropriate certificates installed) my application prematurely terminates with the following error: *** glibc detected *** corrupted double-linked list: 0x0807c830 *** Abort. (Without an SSL connection (as set in ph_hba.conf) the program executes just fine. This leads me to cast suspicion on SSL libraries.) The back trace from gdb looks like this (which doesn't appear to be too informative, but looks like an exception stack): #0 0x401bc851 in kill () from /lib/libc.so.6 #1 0x4014a309 in pthread_kill () from /lib/libpthread.so.0 #2 0x4014a6c0 in raise () from /lib/libpthread.so.0 #3 0x401bc606 in raise () from /lib/libc.so.6 #4 0x401bd971 in abort () from /lib/libc.so.6 #5 0x401ef930 in __fsetlocking () from /lib/libc.so.6 #6 0x401f52b9 in malloc_usable_size () from /lib/libc.so.6 #7 0x401f5395 in malloc_usable_size () from /lib/libc.so.6 #8 0x401f5a43 in malloc_trim () from /lib/libc.so.6 #9 0x401f5d51 in free () from /lib/libc.so.6 #10 0x4052ce6c in zcfree () from /usr/lib/libz.so.1 #11 0x4052f83f in inflateEnd () from /usr/lib/libz.so.1 #12 0x4040f262 in COMP_rle () from /usr/lib/i686/cmov/libcrypto.so.0.9.8 #13 0x0807e680 in ?? () #14 0x in ?? () After a bit of digging around online, I discovered the MALLOC_CHECK_ environment variable and how it changes the behavior of malloc (man 3 malloc). The above back trace was without MALLOC_CHECK_ in the environment (e.g., unsetenv MALLOC_CHECK_). Running with MALLOC_CHECK_ equal to 2 or 1 allows my program to run to completion. With MALLOC_CHECK_ set to 0 (which is supposed to ignore corruption), I get a segfault. Running inside gdb gets me the following back trace: #0 0x403d6f73 in ASN1_template_free () from /usr/lib/i686/cmov/libcrypto.so.0.9.8 #1 0x403d6e0d in ASN1_primitive_free () from /usr/lib/i686/cmov/libcrypto.so.0.9.8 #2 0x403d7023 in ASN1_item_free () from /usr/lib/i686/cmov/libcrypto.so.0.9.8 #3 0x403d0c07 in X509_CERT_AUX_free () from /usr/lib/i686/cmov/libcrypto.so.0.9.8 #4 0x403d077a in X509_CINF_free () from /usr/lib/i686/cmov/libcrypto.so.0.9.8 #5 0x403d6e35 in ASN1_primitive_free () from /usr/lib/i686/cmov/libcrypto.so.0.9.8 #6 0x403d7023 in ASN1_item_free () from /usr/lib/i686/cmov/libcrypto.so.0.9.8 #7 0x403d0927 in X509_free () from /usr/lib/i686/cmov/libcrypto.so.0.9.8 #8 0x402d16f3 in pqsecure_destroy () from /usr/lib/libpq.so.4 #9 0x402c387a in PQconninfoFree () from /usr/lib/libpq.so.4 #10 0x402c39c3 in PQfinish () from /usr/lib/libpq.so.4 #11 0x4002f41b in ECPGget_connection () from /usr/lib/libecpg.so.5 #12 0x40030223 in ECPGdisconnect () from /usr/lib/libecpg.so.5 #13 0x0804a113 in DBDisconnect (arg_connection=0x8054faf "client_correctness") at client_test.pgcc:215 #14 0x0804a64e in DoCorrectnessChecks () at client_test.pgcc:278 #15 0x0804aaa1 in main (argc=7, argv=0xba84) at client_test.pgcc:523 PURE SPECULATION: It looks like there is either trouble in the interaction between Postgres and the SSL library or just a bit of trouble within the SSL library. SPECULATION: Another possibility is that I misunderstand some aspect of multi-threaded interactions with Postgres (I open uniquely named connections to the DB for each thread of my test program). Maybe I need to have a "lock" around the code that makes DB connections and make sure that only one happens at a time (might be better handled within Postgres/SSL if that is the case). PROCEEDING FURTHER: If there is any desire on the part of any developers to pursue this further, I'm open. As things stand right now, I have workarounds: 1. Don't use an SSL connection to the DB. 2. Do a "setenv MALLOC_CHECK_ 1" (or 2) and it works. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2246: Bad malloc interactions: ecpg, openssl
Andy Klosterman wrote: > Before going into a full description and figuring out some example code for > this situation, I'm fishing for interesting in tracking it down and fixing > it (or not). Whenever there is a bug that causes a crash, there is interest in tracking it down and fixing it. Please do provide a test case. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #2243: Postgresql fails to finish some queries
On Tue, Feb 07, 2006 at 02:41:03 +, Matej Rizman <[EMAIL PROTECTED]> wrote: > > Files a_3.txt and b_3.txt contain 3 numbers each. > > The last query (SELECT) is executed on my machine in 125ms. > > If I load data from files a_10.txt and b_10.txt that contain 10 > numbers each, the last SELECT does not finish in more than ten minutes (the > real-world sample hasn't finished in more than an hour). Did you do an ANALYZE after doing the load? ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #2236: extremely slow to get unescaped bytea data
On Wed, Feb 08, 2006 at 09:52:33AM -0800, Kalador Tech Support wrote:
> $tfetch = microtime(true);
>
> // Convert to binary and send to the browser
> // header('Content-type: image/gif');
> header('Content-type: text/plain');
> $data = pg_unescape_bytea($raw);
> $dt = microtime(true) - $tfetch;
The header call should be outside the section of code you're timing.
It probably doesn't matter, but the idea is to time pg_unescape_bytea
so that's all that should be timed (I agree with your decision to
time pg_fetch_result separately).
> When run from a browser, accessing an Apache webserver, the results
> displayed were:
>
> fetchtime = 3.632ms, 296043 bytes
> unescape time = 70625.518ms, 296043 bytes
>
> When running the same code from command line php, the results were:
>
> fetchtime = 3.618ms, 296043 bytes
> unescape time = 8.298ms, 296043 bytes
>
> Am running Apache 1.3.33. I can't figure the difference between
> environments - command line php and apache php are compiled the same
> (except for the --with-apxs=... instruction for apache version).
Something must be different, although offhand I can't think of what it
might be. Locale settings, perhaps? I don't know if pg_unescape_bytea's
performance could be affected by that, but I've seen locale settings
cause horrible performance in string-manipulating code before.
> As an aside, I'm now using base64 encode/decode to insert data without
> problems. For GIF images, at least, it is also a much smaller encoding
> than the escape_bytea encoding.
Too bad PHP's PostgreSQL extension doesn't handle binary results
(or does it?). With a binary cursor or a way to tell pg_query and
friends that you want binary results, you could retrieve the binary
image data without having to mess with encoding and decoding.
Even if you're satisfied with what you're doing, it would be
interesting to find an explanation for pg_unescape_bytea's performance
discrepancy and determine whether it's a problem with PHP or with
the underlying libpq function. Please let us know if you find
anything.
--
Michael Fuhr
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [BUGS] BUG #2246: Bad malloc interactions: ecpg, openssl
"Andy Klosterman" <[EMAIL PROTECTED]> writes: > SPECULATION: Another possibility is that I misunderstand some aspect of > multi-threaded interactions with Postgres (I open uniquely named connections > to the DB for each thread of my test program). Maybe I need to have a > "lock" around the code that makes DB connections and make sure that only one > happens at a time (might be better handled within Postgres/SSL if that is > the case). There could be some re-entrancy problem in the SSL connection startup code --- if you add such a lock, does it get more reliable? Also, did you remember to build PG with --enable-thread-safety ? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [BUGS] date overflows
Kris Jurka <[EMAIL PROTECTED]> writes: >> On Sat, Dec 03, 2005 at 07:53:23PM -0500, Kris Jurka wrote: >>> I'm seeing some date input overflows here. > This seems to fix it. Applied as far back as 8.0 (a rather arbitrary cutoff but seemed reasonable). regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] Please get me out of this ASAP
My name is shyamkumar. Right now I am using Postgres as backend for development. And J2ee technology as front end. Now I have a situation like the sequence id is repeating. This applicaton is running since from 1999, this is the first time we get such a result. I will give you more detail, 1. This is the code we used to create sequence "seq_type_code" CREATE SEQUENCE "public"."seq_type_code" INCREMENT 1 MINVALUE 10 MAXVALUE 9223372036854775807 START 10 CACHE 1; 2 This is query we used to insert value, here we were using the sequence. insert into tour_type(type_code,type_name,from_tour_num,end_tour_num)
values(nextval('seq_type_code'),'type_name',tourRangeFrom,tourRangeTo); 3. This is the result we getting, see type code is repeating here type_code | type_name | from_tour_num | end_tour_num ---+---+---+-- 10 | TEST TOUR | 1 | 99 10 | FRANCE TEST
TOUR | 100 | 199 11 | GERMENY TEST TOUR | 200 | 299 12 | HOLLAND TEST TOUR | 300 | 399 I would like to know more about this, and I have to submit a detailed presentaton about this. Hope you will provide valid informations and will help us to recover from this situation. Yours Sinc
erly,
P.Shyamkumar Software Engineer Maxxion Systems.
Jiyo cricket on Yahoo! India cricket
Yahoo! Messenger Mobile Stay in touch with your buddies all the time.
