linux-c-programming.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Jackson <pj@sgi.com>
To: Christian Stalp <christian.stalp@gmx.de>
Cc: linux-c-programming@vger.kernel.org
Subject: Re: sprintf with mips
Date: Tue, 12 Feb 2008 10:31:37 -0600	[thread overview]
Message-ID: <20080212103137.c74196c4.pj@sgi.com> (raw)
In-Reply-To: <20080210222559.17830@gmx.net>

Does the problem go away if you replace:
	char insertvalues[256];
with something like:
	char xx[512];
	char *insertvalues = xx+128;

If that makes the problem go away, try adding additional checking
code, that puts a distinct guard pattern on both sides of the
256 payload bytes, and checks that pattern for corruption on each
iteration of the while loop.

If the "works on x86 but not mips" is not helping you solve this,
then -ignore- that detail.  This is similar to the "worked before,
but not now, and I only changed such-and-such".  Sometimes such clues
are reality giving you a head fake.  Instead, just debug the mips case,
as if it were all you knew.  In this particular case, you could explain
the x86 vs mips difference with the hypothesis that since the memory
and stack layout are different, perhaps there is a long standing bug
on both architectures that only happens to manifest itself on the
mips architecture.  But you don't need any such explaination -- always
try ignoring such 'strange coincidences' if they are blocking you.

Does this fail sometimes on the -very- first iteration of the
"while(1)" loop, or always sometimes later.

Could some other thread be trampling insertvalues[]?

Could the following line trample insertvalues[]:
	insertinto(dbName, conn, tabellename, insertvalues);

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.940.382.4214

  parent reply	other threads:[~2008-02-12 16:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-10 22:25 sprintf with mips Christian Stalp
2008-02-12 14:17 ` Stephen Kratzer
2008-02-12 16:31 ` Paul Jackson [this message]
  -- strict thread matches above, loose matches on Subject: below --
2008-02-06 22:48 Christian Stalp
2008-02-07  0:10 ` Paul Jackson
2008-02-06 20:14 Christian Stalp
2008-02-06 19:58 Christian Stalp
2008-02-06 19:16 Christian Stalp
2008-02-06 19:45 ` Manning, Gary L
2008-02-06 21:21 ` Eric Polino

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080212103137.c74196c4.pj@sgi.com \
    --to=pj@sgi.com \
    --cc=christian.stalp@gmx.de \
    --cc=linux-c-programming@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).