skip_typespec abort

[Ken Cline]

Marcus,

I'm trying to run swarm on a new Ultra5 with Solaris 7 and my
application keeps aborting while trying to build a ProbeMap.
In particular, the `skip_typespec(const char *)' function in
swarm_rts_routines.m gets an input that causes it to abort
(ie the default case for the switch)*.

Here's the scenario:
   1. BatchSwarm creates a ModelSwarm which (as part of the
      `create' method) tries to create and set a default
      ProbeMap.

   2. When the ModelSwarm calls the ProbeLibrary's 
      `getProbeForVariable:inClass:' method for the first
      time, this causes the ProbeLibrary to "lookup" the
      ProbeMap for the specified class.

   3. The lookup (ie `getProbeMapFor:') method finds no
      existing map for the ModelSwarm class so it proceeds
      to build a ProbeMap, right.

   4. Next, when the new ProbeMap's createEnd method is
      called, it runs thru a loop to add a MessageProbe for
      each method in the method list.

   5. While creating one of these MessageProbes, in particular
      when `createEnd' calls `getArgCount', the code fails
      because its trying to parse a probedType 
      address@hidden:+12' (without the single quotes).

Have you seen this before?  Do you think the probedType
specifer is being corrupted in some way?  Or could this have
something to do with my setup.

My tool chain:  Because I didn't have alot of time to try
to build this Sun from the ground up, I elected to use as
many pre-built binary packages as I could.  In particular,
I used pkgadd to installed the following tools (from
Sunfreeware.com):
   - gcc-2.8.1  (Note: they have 2.95, but they indicated that gdb
         had been built with 2.8.1)
   - gdb-4.18
   - tcl/tk-8.0.3
   - xpm-3.4k
   - zlib-1.1.3

and so on.  I did have to install some stuff from source,
ie blt-2.4i, libffi-1.20, png-1.0.3 and, of course,
swarm-1.4.1.

BTW, Heatbugs seems to work fine, but I didn't really test
it too heavily. GDB also seems to work fine with Heatbugs,
but it can't even load my executable.

Running gdb on gdb and its core dump, I get the following
back trace:
  Core was generated by `gdb swarrior'.
  Program terminated with signal 11, Segmentation Fault.
  Reading symbols from /usr/lib/libcurses.so.1...done.
  Reading symbols from /usr/lib/libsocket.so.1...done.
  Reading symbols from /usr/lib/libnsl.so.1...done.
  Reading symbols from /usr/lib/libdl.so.1...done.
  Reading symbols from /usr/lib/libm.so.1...done.
  Reading symbols from /usr/lib/libc.so.1...done.
  Reading symbols from /usr/lib/libmp.so.2...done.
  Reading symbols from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1...done.
  Reading symbols from /usr/lib/libthread_db.so.1...done.
  #0  0x12e2c4 in demangle_fund_type (work=0xffbef5d0, mangled=0xffbef5b8, 
result=0x1ad968)
    at cplus-dem.c:3367
  3367    cplus-dem.c: No such file or directory.
  (gdb) bt
  #0  0x12e2c4 in demangle_fund_type (work=0xffbef5d0, mangled=0xffbef5b8, 
result=0x1ad968) at cplus-dem.c:3367
  #1  0x12dab4 in do_type (work=0xffbef5d0, mangled=0xffbef5b8, 
result=0x1ad968) at cplus-dem.c:3194
  #2  0x12e7dc in do_arg (work=0xffbef5d0, mangled=0xffbef5b8, 
result=0xffbef420) at cplus-dem.c:3620
  #3  0x12ed20 in demangle_args (work=0x35d80000, mangled=0x0, declp=0x1) at 
cplus-dem.c:3922
  Cannot access memory at address 0x31780038.

I think this may be an unrelated problem, though.

Thanks in advance for any help you provide.

Ken.

*PS: It might be nice if there was some type of error
message before the abort.

_________________________________________________________
Ken Cline                             address@hidden
SAIC                                 VOICE (410) 571-0413
Annapolis, MD                          FAX (301) 261-8427



                  ==================================
   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.