Re: Initialization problem

New Message Reply Date view Thread view Subject view Author view

Steve Baker (steve++at++mred.bgm.link.com)
Wed, 24 Jul 96 11:15:42 -0500

I can also reproduce this same core dump with my application if I fork
DBASE off to another process but keep ISECT, APP, CULL and DRAW together.

If I split DRAW off (so I have DBASE ISECT/APP/CULL DRAW as three processes)
then the problem goes away!

Here is my stack backtrace:

> 0 pfBuffer::pf_destroyMem(pfMemory*)(0x10299590, 0x185a05b0, 0x28141140, 0x185996c8) ["../../../lib/libpf/pfBuffer.C":1377, 0x57adf0]
   1 pfDBase(0x10299590, 0x185a05b0, 0x28141140, 0x185996c8) ["../../../lib/libpf/pfProcess.C":2994, 0x55bc74]
   2 mpDBase(void)(0x10299590, 0x185a05b0, 0x28141140, 0x185996c8) ["../../../lib/libpf/pfProcess.C":3095, 0x55c0b4]
   3 pfConfig(0x10299590, 0x181408b0, 0x1, 0x185996c8) ["../../../lib/libpf/pfProcess.C":1705, 0x55855c]
   4 main(argc = 8, argv = 0x7fffaed4) ["/usr/squeaky2/rightview/src/performer/ptask.cxx":1162, 0x4ed0e4]
   5 __start() ["crt1text.s":133, 0x46fbcc]

Does this look familiar Axel?

This particular dump was from an RE2 with Irix 5.3 and Perf 2.0 - but I see the same thing
on iR with Irix 6.2 and Perf 2.1 - so it's an ongoing problem.

I emailed the Performer team about this on April 16th but didn't get an answer - but
since I don't need this mode in normal operation, I never did track down a fix. :-(

FYI: Bernard Leclerc wrote:

> I obtain the same result: a SIGSEGV, a core dump, and the same stack trace -
> which BTW doesn't make sense at all since the crash supposedly happen in
> pfConfig().

It happens in pfConfig because it is pfConfig that forks off the DBASE
task - so any crash in the DBASE task will appear to be 'inside' pfConfig.

The important thing is that it crashed inside pfDBase - in my case on the very
first call to pfDBase.

---------------------------------------------------------------------------------

On Jul 24, 2:34pm, Axel Schmidt wrote:

> I get a segmentation violation on all our machines.

...

> The stack trace is always the same for all machines:
>
> Core from signal SIGSEGV: Segmentation violation
> (dbx) where
> > 0 pfBuffer::pf_destroyMem(pfMemory*)(0x1000a530, 0x18075d50, 0x5dc08040,
0x0) ["../../../lib/libpf/pfBuffer.C":1377, 0x5ccc464c]
> 1 pfDBase(0x1000a530, 0x18075d50, 0x5dc08040, 0x0)
> ["../../../lib/libpf/pfProcess.C":2994, 0x5cd0d654]
> 2 dbFunc(void*)(0x0, 0x18075d50, 0x5dc08040, 0x0) ["magic.c++":25,
> 0x402c68]
> 3 mpDBase(void)(0x1000a530, 0x18075d50, 0x5dc08040, 0x0)
> ["../../../lib/libpf/pfProcess.C":3093, 0x5cd0da78]
> 4 pfConfig(0x1000a530, 0x18040830, 0x1, 0x0)
> ["../../../lib/libpf/pfProcess.C":1705, 0x5cc9a99c]
> 5 main(0x1000a530, 0x18075d50, 0x5dc08040, 0x0) ["magic.c++":44,
> 0x402d44]
> 6 __start() ["crt1text.s":133, 0x4029fc]

  Steve Baker 817-323-1361 (Vox-Lab)
  Hughes Training Inc. 817-695-8776 (Vox-Office/vMail)
  2200 Arlington Downs Road 817-695-4028 (Fax)
  Arlington, Texas. TX 76005-6171 steve++at++mred.bgm.link.com (eMail)

=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
            Submissions: info-performer++at++sgi.com
        Admin. requests: info-performer-request++at++sgi.com

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:53:13 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.