AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20061116195613.58622eee@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<chris.vandever@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	0	BB375AF679D4A34E9CA8DFA650E2B04E0138C31A@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Thu, 16 Nov 2006 19:56:34 -0800
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Chris Vandever" <chris.vandever@onstor.com>
Subject: Re: vsnprintf problem
Message-ID: <20061116195634.44980aea@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E0138C31A@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E0138C31A@onstor-exch02.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.5.6 (GTK+ 2.8.20; i486-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi Chris,

check out the va_arg(3) function, the man page kinda explains it all.
But like I said, you have to know that the next arg is a certain
size/type, and that is only possible if the vsnprintf function is doing
the right thing as it processes the format specifiers.  If the
arguments get processed through varargs before they get to vsnprintf
then it likely won't work.  I can't remember the details of how it all
went in the code you showed me.

It might be that our C library's vsnprintf implementation is buggy when
it comes to this, and it should be working, but I won't swear to that.
It's quite old now, so it could easily be a bug that has long been fixed.

Try moving that arg to the last in line, and see if you get lucky.

Cheers,

a

 On Wed, 15 Nov 2006 14:34:47 -0800 "Chris Vandever"
<chris.vandever@onstor.com> wrote:

> The source file I'm having problems with is
> ~chrisv/p4/lambo/nfx-tree/code/ssc-cluster/clusdb-rec-r122.c.  The
> problem is with a CLUSTER_PRINTF() at line 417.  Similar
> CLUSTER_PRINTF()'s in code/ssc-cluster/cluster-vol-api.c work fine.
> The former file is only used in building the cluster_server app,
> while the latter is used to build libcluster.so, and the code is then
> exercised by the cluster_contrl app.  CLUSTER_PRINTF() is a macro
> that wraps the standard E_LOG() macro, which eventually works its way
> into vsnprintf().
> 
> What happens is that the 64-bit quantity in volCfg.id.whole_thing is
> off by 32-bits when it gets stuffed into the formatted string, so
> part of the value is correct, but part is from the wrong neighboring
> word.  This ends up shifting the remaining parameters, resulting in a
> SEGV trying to get the length of the string parameter that it's
> trying to pick up from the wrong location.
> 
> I've tried replacing the CLUSTER_PRINTF() macro with a direct E_LOG()
> call without any change in the symptoms.  I've tried doing a clean
> build of ssc-cluster with -DRELIABLE_LOG defined in the Makefile.
> This define enables an alternate definition of CLUSTER_PRINTF() that
> calls a function private to clustering that calls vsnprintf()
> directly to write to a log file, before later calling E_LOG().
> Again, no change.
> 
> The edits to the file are in 3 major areas:  (1) Make the include file
> list match what seems to work in cluster-vol-api.c.  The resulting
> dependency files are identical, except for the addition of
> clusdb-api.c, which contains only function prototypes for clusDb_*()
> functions.  (2) Ifdef out the functions that need the missing include
> files.  (3) Add the offending CLUSTER_PRINTF().
> 
> Since I get the same symptom from the more direct use of vsnprintf() I
> don't think it's related to E_LOG per se.  Since I've pared down the
> file to use the same includes as the file that works I don't think
> it's the include files.
> 
> I have my filer set up to exercise the code, as it requires trying to
> upgrade the cluster database from version R1.3 to R2.1.
> 
> If you have some time to drop by and take a look at this I'd
> appreciate it.  I'd really like to be able to log errors from the
> functions in this file that include the 64-bit volume ID.  Thanks.
> 
> ChrisV
> 
