[HACKERS] SIGSEGV in Postgres 8.0.3 (libpq4)
Hi, I have a set of perl scripts which invoke each other (via system()); eventually I found that they were crashing and ultimately causing Perl to SIGSEGV. I am using Debian testing and have recompiled postgres-8.0.3-15 to include debugging symbols. This is a dual-CPU dual-stacked IPv4/IPv6 host running Linux 2.4.22. From what I have been able to determine the problem is in libpq4: Starting program: /usr/bin/perl ./add_address 265 2001:502:d399:0:0:0:0:44 [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 8523)] (no debugging symbols found) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 8523)] r0x4038275b in pqGetc ( result=0xbfffee0b @[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/[EMAIL PROTECTED]@X���7\0178@, conn=0x401c13d4) at fe-misc.c:85 85 *result = conn-inBuffer[conn-inCursor++]; (gdb) bt #0 0x4038275b in pqGetc ( result=0xbfffee0b @[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]/[EMAIL PROTECTED]@X���7\0178@, conn=0x401c13d4) at fe-misc.c:85 #1 0x40388543 in pqParseInput3 (conn=0x401c13d4) at fe-protocol3.c:80 #2 0x403805f4 in parseInput (conn=Variable conn is not available. ) at fe-exec.c:1097 #3 0x40380f37 in PQgetResult (conn=0x401c13d4) at fe-exec.c:1171 #4 0x403812e4 in PQexecStart (conn=0x401c13d4) at fe-exec.c:1315 #5 0x40381532 in PQexec (conn=0x401c13d4, query=0x82fada8 DEALLOCATE dbdpg_2) at fe-exec.c:1223 #6 0x40367459 in _result () from /usr/lib/perl5/auto/DBD/Pg/Pg.so #7 0x4036da35 in dbd_st_deallocate_statement () from /usr/lib/perl5/auto/DBD/Pg/Pg.so #8 0x4036dfe8 in dbd_st_destroy () from /usr/lib/perl5/auto/DBD/Pg/Pg.so #9 0x40360784 in XS_DBD__Pg__st_DESTROY () from /usr/lib/perl5/auto/DBD/Pg/Pg.so #10 0x40342e65 in XS_DBI_dispatch () from /usr/lib/perl5/auto/DBI/DBI.so #11 0x080c4386 in Perl_pp_entersub () #12 0x080644dc in Perl_call_sv () #13 0x080642b1 in Perl_call_sv () #14 0x080ccc55 in Perl_sv_clear () #15 0x080cd420 in Perl_sv_free () #16 0x080cce19 in Perl_sv_clear () #17 0x080cd420 in Perl_sv_free () #18 0x080b0a1f in Perl_mg_free () #19 0x080cd1ba in Perl_sv_clear () #20 0x080cd420 in Perl_sv_free () #21 0x080c56f4 in Perl_sv_add_arena () #22 0x080c5876 in Perl_sv_clean_objs () #23 0x0806202d in perl_destruct () #24 0x0805fde0 in main () (gdb) I am happy to try out any patches, etc., however I am not on the mailing list, so please CC: any replies to me. Thanks, Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, This you may not read, this you must not see, this you are forbidden to know, the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, If this goes on -- ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] ARC patent
On Mon, 17 Jan 2005 15:07:30 -0500, Bruce Momjian wrote: Jan Wieck wrote: On 1/17/2005 1:15 AM, Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: FYI, IBM has applied for a patent on ARC (AFAICS the patent application is still pending, although the USPTO site is a little hard to grok): http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1Sect2=HITOFFd=PG01p=1u=%2Fnetahtml%2FPTO%2Fsrchnum.htmlr=1f=Gl=50s1=%2220040098541%22.PGNR.OS=DN/20040098541RS=DN/20040098541 Ugh. We could hope that the patent wouldn't be granted, but I think it unlikely, unless Jan is aware of prior art (like a publication predating the filing date). I fear we'll have to change or remove that code. regards, tom lane Unfortunately no. The document that inspired me to adapt ARC for PostgreSQL is from the USENIX File Storage Technologies Conference (FAST), March 31, 2003, San Francisco, CA. Oh, OK. Good news! I am seriously concerned about this and think we should not knowingly release code that is possibly infringing a patent. If we need a different cache algorithm again, we might want to yank out the ARC part right away now and work on another one for 8.1. If you want to poke around for 2 hours, I bet you wil find more patent infringements. And not looking doesn't protect you from patent violations. Not looking does protect you from a willful patent violation lawsuit, as I understand it. Personally I'd be surprised if any commercial entity wanted to take the risk that 15 years down the track the patent is granted retrospectively and that IBM wouldn't come knocking. Especially since 8.0 is now out in the field with the ARC code. Friends don't let friends read patents. Cheers, Anand -- linux.conf.au 2005 - http://lca2005.linux.org.au/ - Birthplace of Tux April 18th to 23rd - http://lca2005.linux.org.au/ - LINUX Canberra, Australia - http://lca2005.linux.org.au/ -Get bitten! ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] CVS should die
On Sat, 06 Nov 2004 11:53:13 +0100, Thomas Hallgren wrote: Andrew McMillan wrote: Switching to Arch is more work, but it also offers a lot more benefits - including the opportunity for individuals to maintain their own trees, and be able to work out which patchsets from someone else's tree have not been applied. If anything is going to become the open-source BitKeeper it will be this, I think. For those interested in SVN versus arch, I found the following from Tom Lord (the guy behind Arch) http://web.mit.edu/ghudson/thoughts/diagnosing and a reply from Greg Hudson (SVN developer) http://web.mit.edu/ghudson/thoughts/undiagnosing. There is a fairly detailed comparison in the GNU Arch wiki as well. URL: http://wiki.gnuarch.org/moin.cgi/SubVersionAndCvsComparison Note: if you're a postgres committer you may have more luck seeking out your nearest SCM advocate -- almost all of them would regard Postgres migrating to their preferred SCM as a 'win' -- let them work for you by walking you through things. Cheers, Anand ---(end of broadcast)--- TIP 8: explain analyze is your friend
