Conference clt::fuse

Thanks for the detailed explaination of the problem!

I assume the ladebug the customer was using before the upgrade was
working OK?

Well, it certainly seems like this has something to do with the
ladebug <-> FUSE integration.  I'm trying to reproduce it...

What's really odd is that it seems that the GUI didn't crash,
the ladebug engine did.  The engine doesn't have any hooks into
FUSE.  It might be something that FUSE is feeding the engine is
causing it to crash.

> By the way -- I notice in the TURRIS::DECLADEBUG conference that
> V4.0-29 and V4.0-30 f.t. are available.
> Will either one of those play properly with FUSE V3.1 ?

These two versions should work with FUSE V3.1.  I've personally
used them both. :)

John

I haven't been able to reproduce it either.

Can you ask the user to check their limits (stack and data)?  It 
should be something like this:

% ulimit -a
time(seconds)        unlimited
file(blocks)         unlimited
data(kbytes)         131072
stack(kbytes)        2048
memory(kbytes)       122040
coredump(blocks)     unlimited
nofiles(descriptors) 4096
vmemory(kbytes)      1048576

If the limits are too low you can ask them to set them higher.  But
I doubt that is the problem.

The best bet is to have the customer upgrade to a newer ladebug
if possible.  If the problem still shows up, I can get a debuggable
version of ladebug that will give us better information about the stack
trace.

John

> The best bet is to have the customer upgrade to a newer ladebug
> if possible.  If the problem still shows up, I can get a debuggable
> version of ladebug that will give us better information about the stack
> trace.

I checked and the customer is willing to give this a try.
Let me know where/when I can retrieve the new version --
I just grabbed a copy of v4.0-30 recently from site labrea:: as mentioned
in note # 2.97 in the DECLADEBUG notes conf.
I can send that to the customer, or I can send your enhanced/debuggable
version -- let me know how to proceed.

--Steve

Try v4.0-30 first...

Tim
(ladebug)

Hi. This is Pat Lampert. I work in Steve Sheppard's team 
(Steve is the note originator) Since Steve last communicated
with you about this problem the following has happend.


o Steve left Digital and this call floated in limbo for awhile.

o I took over the call a couple of weeks ago and...

o Supplied customer with ladebug 4.0-30

o Upgraded the customer to the current release of c++ 5.5
  to make sure his libraries were ok.

o Increased the customers stack and data limits to very
  high values


Unfortunately the customer still gets the following with
fusedebug:


Note:

ladebug and dxladebug seem to be OK. 

I have asked for one other bit of info from the customer:

sysconfig -q proc and vm and ipc didnt show any unusual
settings, but maybe there is some other kernal tuning that I
didnt pick up. I will have him send me his sysconfigtab and his 
kernel config files.

If nothing shows up. Is there a debugger with symbols that I can have
hime run?

Thanks.  Pat 

Current error:...

$ fusedebug helloc

!======================
FUSE output from helloc (C source):

Welcome to the Ladebug Debugger Version 4.0-30
------------------
object file name: helloc
Reading symbolic information ...done
Directory search path for source files:
 . . /usr/users/luis/flb/blib/ /usr/users/luis/flb/slatec41/555/ /home/luis/flb/units/ /usr/apps/slatec/src/
Directory search path for source files:
 . . /usr/users/luis/flb/blib/ /usr/users/luis/flb/slatec41/555/ /home/luis/flb/units/ /usr/apps/slatec/src/
Internal Error: out of memory
Heap exhausted with 268238848 bytes.

Ladebug Debugger Version 4.0-30 caught signal "Segmentation fault" (11).
This is an unexpected condition and may indicate the presence of a defect.
If you wish to report this, please include the stack trace that follows.
Diagnostic stack trace ...
0x123636ec
0x1220125c
0x24241548
0x2424173c
0x12203888
0x1259726c
0x125948ec
0x125970ec
0x24241714
0x12203994
0x1259726c
0x125948ec
0x1259358c
0x1230b89c
0x12210374
0x123e0a80
0x1227d394
0x1227ba50
0x2424b2f0
0x122787b8
0x1227ba50
0x2424b2f0
0x1227cc4c
0x1227ba50
0x2424b2f0
0x12278ad0
0x1227ba50
0x2424b2f0
0x1227ac70
0x1227ba50
0x2424a92c
0x2424a568
0x1227c974
0x122aabf8
0x122a7d78
0x122447fc
0x1221ac88
0x12206154
0x121f61d4
0x121f32dc
end of diagnostic stack trace.

$ cat hello.c
#include <stdio.h>
main() {
printf("hello world\n");
}

This is a perplexing problem!

I'm trying to find a way to get you a debuggable copy of ladebug.


I assume from the startup messages that the customer has a 
.dbxinit file.  Can we see it?  I imagine that it has something 
like:

use . /usr/users/luis/flb/blib/ /usr/users/luis/flb/slatec41/555/ /home/luis/flb
/units/ /usr/apps/slatec/src/
use . /usr/users/luis/flb/blib/ /usr/users/luis/flb/slatec41/555/ /home/luis/flb
/units/ /usr/apps/slatec/src/

in it.

Also, does the user have their home directory mounted twice?  I see
/usr/users/luis and /home/luis in the search path.

John

Pat, I haven't heard from you in a bit, but the debuggable ladebug
kit should be on ftp://paradise.zko.dec.com/pub/LDB436.tar.gz

The ladebug folks tell me that they have fixed a couple similar
bugs, so this release may work ok for the customer.

John

Turns out that the customer had a .dbxinit which was doing a 
"record input" command. I should kick myself for not asking
for a copy of the .dbxinit when I first took over this call.
The "record input" problem is already known. I reported it
back in April of 96.

Thanks for your help.

Pat Lampert     CSC Atlanta