Message 1/1560  From Nitin Sonawane                 Nov 06, 06 08:04:04 PM -0500
To: "Bob Lechner" <lechner@cs.uml.edu>
Subject: Re: why the chgen binary is not compatible - OK Nitin
RJLRef: $PH/COOL-GEN/chgen13/chgen/src/emptyTableBug_ns061106.txt
Prof. Lechner,

It is very easy to reproduce the problem using my code. What
I found was that even after a pr_add() of a table element example,
aa_elt, the pr_add call returned but AA continued to be NULL
(rather than point to the newly created aa_elt). Subsequent calls
to pr_dump() do not work but that is not surprising .

I even single stepped through gdb to see what might be going
wrong but wasn't able to do much diagnosis. I should be able to
demonstrate this to you tomorrow (perhaps after class?) and we
can step through the debugger.

Thanks,
Nitin.

On 11/5/06, Bob Lechner <lechner@cs.uml.edu> wrote:
>
> I do agree. That's OK Nitin.
> However if you have trouble with pr_*.c files
> you might want to do cvs update and rebuild chgen13.
> I made some changes to gen_*.c files in case/gen/ver_13..
> and checked them into CVS.
>
> I didn't solve my problems with pr_dump however.
> It may be because of what you discovered - that
> a non-empty table is needed to start off.
> Now that didn't use to happen so it's probably a bug that
> I introduced. I would like to know details of how you
> discovered it so I can try correcting it at its source.
>
> One thing I tried experimentally is to avoid version#
> sensitivity in VMNetDB (and in viewdef files).
> I may have partly updated chgen with some artifacts remaining.
> One possibility is the XX01000n row #s - the 01(hex) is version# 1
> and pr_dump may be selecting version#0.
> Do you call pr_dump to a .dat file and does it work?
>
> Bob Lechner