portsdb and ruby bug on 4-STABLE

[Chris]

Vulpes Velox wrote:
> On Mon, 6 Sep 2004 16:24:57 +0300 (EEST)
> Dmitry Pryanishnikov <dmitry at atlantis.dp.ua> wrote:
> 
> 
>>Hello!
>>
>>  I'm hitting notoriuos bug during the portsdb -u last several days:
>>
>>root at core# portsdb -fu
>>[Updating the portsdb <format:bdb1_btree> in /usr/ports ... - 10078
>>port entries found 
>>.........1000.........2000.........3000.........4000.........5000..
>>.......6000.........7000../usr/local/lib/ruby/site_ruby/1.8/portsdb
>>.rb:587: [BUG] Segmentation fault
>>ruby 1.8.2 (2004-07-29) [i386-freebsd4]
>>Abort trap (core dumped)
>>
>>Machine has ECC memory and is rock-solid, so I'd say it's definitely
>>a software bug. Machine is running 4.9-RELEASE-p11, the same
>>behaviour is seen on another PC, running 4.10-RELEASE-p2. However,
>>my third server, running 4.7-RELEASE, doesn't trap with the same
>>ports collection and the same INDEX generation procedure (I use
>>portindex). Versions of the involved software are the same on all
>>three machines:
>>
>>portindex-18_1      Incremental ports INDEX file builder
>>portupgrade-20040701_3 FreeBSD ports/packages administration and
>>management python-2.3.4_2      An interpreted object-oriented
>>programming language ruby-1.8.2.p2_1     An object-oriented
>>interpreted scripting language ruby18-bdb1-0.2.2   Ruby interface to
>>Berkeley DB revision 1.8x with full
>>
>>So I'm curious, why this bug doesn't show under 4.7-RELEASE but
>>shows under 4.9+? libc issue?
>>
>>P.S. BTW ruby sometimes runs into infinite loop instead of crashing
>>(if it helps someone). Of course, I use portindexdb as a workaround.
> 
> 
> fix it using rm INDEX* and then rebuild the index using portindex and
> then rebuild the INDEX.db using portindexdb. Port upgrade now works
> again. I have not seen this problem on for X, but did once on
> 5.3beta3.

Oh, and as a follow-up: I did another cvsup not more then an hour ago - 
portsdb - still bombs.

-- 
Best regards,
Chris

In order for something to become clean, something
else must become dirty.
... but you can get everything dirty without getting
anything clean.