463208 - Possible leak in sqlite3UnixFullPathname().

Status: RESOLVED WONTFIX

(NSS :: Libraries, defect, P5)

Description

[Slavomir Katuscak]

When using vfychain with Shared Databases (NSS_DEFAULT_DB_TYPE="sql") on Solaris, DBX detects blocks in use:

Block in use (biu):
Found block of size 98 bytes at address 0x10013de48 (5.43% of total)
At time of allocation, the call stack was:
    [1] _strdup() at 0xffffffff5ed5ba98
    [2] _getcwd() at 0xffffffff5ed43800
    [3] sqlite3UnixFullPathname() at line 14169 in "sqlite3.c"
    [4] sqlite3PagerOpen() at line 18448 in "sqlite3.c"
    [5] sqlite3BtreeOpen() at line 22665 in "sqlite3.c"
    [6] sqlite3BtreeFactory() at line 64249 in "sqlite3.c"
    [7] openDatabase() at line 64455 in "sqlite3.c"
    [8] sqlite3_open() at line 64530 in "sqlite3.c"
    [9] sdb_openDB() at line 597 in "sdb.c"
    [10] sdb_init() at line 1691 in "sdb.c"
    [11] s_open() at line 1972 in "sdb.c"
    [12] sftk_DBInit() at line 2286 in "sftkdb.c"
    [13] SFTK_SlotReInit() at line 2084 in "pkcs11.c"
    [14] SFTK_SlotInit() at line 2189 in "pkcs11.c"
    [15] nsc_CommonInitialize() at line 2549 in "pkcs11.c"
    [16] NSC_Initialize() at line 2605 in "pkcs11.c"

sqlite3UnixFullPathname() source is:
char *sqlite3UnixFullPathname(const char *zRelative){
  char *zFull = 0;
  if( zRelative[0]=='/' ){
    sqlite3SetString(&zFull, zRelative, (char*)0);
  }else{  
    char *zBuf = sqliteMalloc(5000);
    if( zBuf==0 ){
      return 0;
    }
    zBuf[0] = 0;
    sqlite3SetString(&zFull, getcwd(zBuf, 5000), "/", zRelative,
                    (char*)0);
    sqliteFree(zBuf);
  }

zBuf is allocated, then there are copied some data in getcwd() command and finally it's released so it looks like the problem is not directly in sqlite.

Found on Solaris 9/Sparc. On Linux this bug doesn't occur. It's possible that problem is in Solaris getcwd implementation, but rather review it and close as INVALID if it's not sqlite problem.

Comment 1

[Slavomir Katuscak]

Adding pattern to list of ignored leaks:
**/sqlite3UnixFullPathname/_getcwd/**

Comment 2

[Robert Relyea]

The bug appears to be in getcwd. It can be one of 3 things:

1) a real bug in the Solaris 9/Sparc implementation.
2) a one time leak in getcwd on Solaris 9/Sparc
3) nonstandard behavior of Solaris 9/Sparc 

A quick look at the man pages (including solaris man pages) indicate that getcwd does not return any allocated memory, excepted in the Linux extension of supplying NULL as the buffer (not POSIX). In all POSIX cases it uses the buffer supplied and returns an error if the buffer is too small. The code clearly never supplies NULL to the function (if the malloc failed, the function itself returns '0'.

bob

Comment 3

[Julien Pierre]

Slavo,

What system did the problem occur on ? I tried isolating a single call to cwd on mace, which Solaris 9 sparc, and couldn't reproduce the problematic behavior. getcwd did not end up calling strdup . Perhaps this is a bug in Solaris that has already been fixed. If so, we should upgrade the machine in question to the latest s9 patch level.

Comment 4

[Slavomir Katuscak]

Julien, you can see this leak for example on aquash Tinderbox.

$uname -a
SunOS aquash 5.9 Generic_122301-32 i86pc i386 i86pc

Comment 5

[Julien Pierre]

Slavo,

I don't see the problem on aquash with a simple invocation of getcwd . I do see that getcwd calls strdup, but this isn't reported as a leak by dbx.

aquash cannot be the original machine since it is 32-bit x86, and comment 0 says it happened on Sparc. The stack shows it's 64-bit. Can you report what the original machine was ?

Comment 6

[Slavomir Katuscak]

Julien, most probably this bug was reported on ciotat (this time it was Solaris/Sparc Tinderbox) - later there were switched Tinderboxes for standard and for memory leak tests - harpsichord (S10) and ciotat (S9), I don't see this bug more on harpsichord (maybe S9 problem). Aquash is another S9 tinderbox running memory leaks, but as you already mentioned it's x86 machine. I see this bug is still there (you can search for it in Tinderbox logs, just grep for string 463208).

You can find full leak report in directory:
/export/tinderlight/data/aquash_32_DBG.last.1/mozilla/tests_results/security/aquash.1/sharedb/memleak_logs

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Unsetting target milestone in unresolved bugs whose targets have passed.

Comment 8

[Slavomir Katuscak]

After changes in sqlite3 (bug 494603), there are new stacks detected, however it is the same problem (see bug 494603 comment 13). I'm going to add new pattern **/unixFullPathname/_getcwd/** to list of ignored stacks, to catch also these stacks.