Re: Any one using Compaq(DEC) Tru64 UNIX?

[W . Northcott]

After much grovelling I have gdb working a treat.

Marcus wrote
>BN> collections:archiver    (HDF5Object.m :800   'differing source and
target
>BN> types')
>BN> defobj:archiver (HDF5Object.m :800   'differing source and target
types')

>I bet it has to do with a lack of typing by GCC for 64 bit types of
>some kind.  It should print out too integers after that..

The full message is 'Differing source and target types 11/8'

>BN> defobj:Forwarding    (Just what is going on around L506 of
>BN> libobjc/sendmsg.c where it mentions fragile code??)

>GCC has a half-working means by which you can indicate arguments
>and construct a call on the fly.  On some systems it doesn't work,
though, and
>figuring out where values land in a call frame must done by hand.
>You might try the optimistic __builtin_return default and see
>if the tests pass.

It seems that your comment about GCC getting in a mess with 64 bit types
is the problem.  When ArtStkMkt breaks the agents profit is -1.1e308 .  He
was obviously trading dot coms.

I am still having difficulty seeing which bit of code to attack.  When
archiver.m breaks the stack looks like this:

(gdb) info stack
#0  0x3ff801182c4 in __tis_raise ()
#1  0x3ff8016b214 in raise ()
#2  0x3ff80189114 in abort ()
#3  0x120104cd4 in debugabort (filename=0x140097b54 "Symbol.m",
lineno=173,
    function=0x140097cc8 "-[Error(c) _raiseEvent:]") at debugabort.c:9
#4  0x1200cc688 in -[Error(c) _raiseEvent:] (self=0x1400faf10,
_cmd=0x1400382d8,
    eventData=0x140096396) at Symbol.m:173
#5  0x1200c2b68 in process_ivar (ivarName=0x140071def "longVal",
ivarType=fcall_type_ulonglong,
    val_ptr=0x1401900b8, rank=0, dims=0x0) at HDF5Object.m:799
#6  0x1200a07d4 in map_class_ivars (class=0x1400009f0) at internal.m:281
#7  0x1200a0850 in map_objc_ivars (obj=0x140190090,
process_object=0x11fff9740) at internal.m:289
#8  0x1200a437c in map_object_ivars (object=0x140190090,
process_object=0x11fff9740)
    at internal.m:1048
#9  0x1200c2ce0 in -[HDF5CompoundType(c) _packBuf:to:] (self=0x14014cd90,
_cmd=0x140038c48,
    obj=0x140190090, buf=0x11fff9778) at HDF5Object.m:807
#10 0x1200ca2a0 in -[HDF5(c) _shallowStoreObject:] (self=0x140189390,
_cmd=0x140032f18,
    obj=0x140190090) at HDF5Object.m:1918
#11 0x1200b08d0 in -[Object(s) _hdf5OutShallow:] (self=0x140190090,
_cmd=0x140064f50,
    hdf5Obj=0x140189390) at DefObject.m:1048
#12 0x1200ed700 in -[List(any) _hdf5OutShallow:] (self=0x140184790,
_cmd=0x1400365f8,
    hdf5Obj=0x140177290) at List.m:306
#13 0x1200bc7a4 in -[HDF5Archiver(c) _putShallow:object:]
(self=0x1400e3e90, _cmd=0x140000e90,
    key=0x140071976 "collection", object=0x140184790) at
HDF5Archiver.m:163
#14 0x120022aa8 in -[Controller updateArchiver:] (self=0x14016ccd0,
_cmd=0x1400347e0,
    archiver=0x1400e3e90) at archiver.m:326
#15 0x1200adc54 in -[Object(s) _perform:with:] (self=0x14016ccd0,
_cmd=0x14005efe0,
    aSel=0x1400347e0, anObject1=0x1400e3e90) at DefObject.m:574
#16 0x1200da808 in -[Collection(any) _forEach::] (self=0x140189410,
_cmd=0x1400347f0,
    aSelector=0x1400347e0, arg1=0x1400e3e90) at Collection.m:228
#17 0x1200b6298 in -[Archiver(c) _updateArchiver] (self=0x1400e3e90,
_cmd=0x1400366a8)
    at Archiver.m:182
#18 0x1200bcd14 in -[HDF5Archiver(c) _sync] (self=0x1400e3e90,
_cmd=0x140000fb0)
    at HDF5Archiver.m:200
#19 0x120023210 in -[Controller createCollectionAndSave]
(self=0x14016ccd0, _cmd=0x1400011b0)
    at archiver.m:373
#20 0x120023fac in checkArchiver (aZone=0x140102790, hdf5Flag=1 '\001',
deepFlag=0 '\000',
    mapFlag=0 '\000', updateFlag=1 '\001') at archiver.m:486
#21 0x12002486c in main (argc=1, argv=0x11fffa018) at archiver.m:535

Any suggestions about where to grovel in that lot??

Bill Northcott



                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.