sprintf with mips

The whole procedure is here: (its a thread!)

void *dblogger_fn (void *arg)

{
	char insertvalues[256];
	memset (insertvalues, 0x0, 256 );
        conn = PQconnectdb("host=192.168.1.2 dbname=wlan_db  user=gavle password=brynaes");
        tabellename = "traffic";
	
	if (PQstatus(conn) == CONNECTION_BAD) 
	{
		fprintf(stderr, "Connection to database '%s' failed.\n",dbName);
		fprintf(stderr, "%s", PQerrorMessage(conn));
		exit_nicely(conn);
  	}
  	else if (PQstatus(conn) == CONNECTION_OK) 
  	{
  		printf("Connected with database ...\n");
  		printf("Datenbank : %s\n", PQdb(conn));
  		printf("User      : %s\n", PQuser(conn));
  	}
  	while(1)
  	{
  		sleep(500);
  		snprintf(insertvalues, 255 ," %d , ' %s ' , %d ", counter, "192.168.1.1", mytraffic->num_frames);
  		printf("input-string: %s\n", insertvalues);
  		printf("Counter: %d\n", counter);
		insertinto(dbName, conn, tabellename, insertvalues);
		counter++;

}

I don't know where is here a chance for an overflow? Consider, now with 'snprintf' it works, but before with sprintf there was this problem, BUT only on the mips-target board. On x86 it worked also with sprintf!

Gruss Christian

Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

I would recommend stepping through with a debugger. It might also be worth while to compile with the -S option (if using gcc) and peruse the MIPS assembly.

Stephen Kratzer
Network Engineer
CTI Networks, Inc.

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 <[email protected]> 1.940.382.4214