RE: Core dumps on Solaris when compiled with threads

Greg
 
Thank you for alerting us all to this Solaris bug.  It exists on Solaris 2.6
as well.
However using a char array may not be ideal.  I believe the conventional
solution
is more as follows:
 
For HTMulti.c

--- 310,312 ---
<  #ifdef HT_REENTRANT
<      struct dirent *result;                    /* For readdir_r */
<      int name_max;
---
>  #ifdef HT_REENTRANT
>      struct dirent result;                     /* For readdir_r */
--- 336,345 ---
<  #ifdef HT_REENTRANT
<      name_max = pathconf(dirname, _PC_NAME_MAX);
<      result = HT_MALLOC(sizeof(struct dirent) + name_max + 1);
<  #endif
<  #ifdef HAVE_READDIR_R_2
<      while ((dirbuf = (struct dirent *) readdir_r(dp, result))) {
<  #elif defined(HAVE_READDIR_R_3)
<      while (readdir_r(dp, result, &dirbuf) == 0) {
---
>  #ifdef HAVE_READDIR_R_2
>      while ((dirbuf = (struct dirent *) readdir_r(dp, &result))) {
>  #elif defined(HAVE_READDIR_R_3)
>      while (readdir_r(dp, &result, &dirbuf) == 0) {
--- 384,388 ----
<      closedir(dp);
---
>      closedir(dp);
> #ifdef HT_REENTRANT
>      HT_FREE(result);
> #endif


HTFile.c

--- 175,179 ---
<  #ifdef HT_REENTRANT
<        struct dirent *result;                /* For readdir_r */
<        int name_max = pathconf(file->local, _PC_NAME_MAX);
<        result = HT_MALLOC(sizeof(struct dirent) + name_max + 1);
---
>  #ifdef HT_REENTRANT
>        struct dirent result;                 /* For readdir_r */
--- 181,185 ---
<  #ifdef HAVE_READDIR_R_2
<        while ((dirbuf = (struct dirent *) readdir_r(dp, result)))
<  #elif defined(HAVE_READDIR_R_3)
<        while (readdir_r(dp, result, &dirbuf) == 0)
---
>  #ifdef HAVE_READDIR_R_2
>        while ((dirbuf = (struct dirent *) readdir_r(dp, &result)))
>  #elif defined(HAVE_READDIR_R_3)
>        while (readdir_r(dp, &result, &dirbuf) == 0)
--- 226,230 ---
<        HTDir_free(dir);
---
>        HTDir_free(dir);
>  #ifdef HT_REENTRANT
>        HT_FREE(result);
>  #endif

That is, you malloc a struct dirent plus whatever pathconf() returns as the
max name length for the particular filesystem the directory resides on.


 

-----Original Message-----
From: Gregory E. Moltchadski [mailto:agent.smith@atcsim.de]
Sent: Friday, March 09, 2001 06:11 AM
To: www-lib@w3.org
Subject: BUG: Core dumps on Solaris when compiled with threads


Hi!
 
LIBWWW produces core dumps on Solaris 7 and 8 when compiled with thread
support.
(try "chunk file:///usr/include <file:///usr/include> " for example).
 
The bug is in HTFile.c and HTMulti.c in "readdir_r" function calls:
 
---------------------------------------------------------
diff HTMulti.c HTMulti.c.buggy
311c311
<     char result[512];             /* For readdir_r */
---
>     struct dirent result;             /* For readdir_r */
337c337
<  while ((dirbuf = (struct dirent *) readdir_r(dp, (struct dirent
*)result))) {
---
>  while ((dirbuf = (struct dirent *) readdir_r(dp, &result))) {
339c339
<         while (readdir_r(dp, (struct dirent *)result, &dirbuf) == 0) {
---
>         while (readdir_r(dp, &result, &dirbuf) == 0) {
---------------------------------------------------------
diff HTFile.c HTFile.c.buggy
177c177
<  char result[512];        /* For readdir_r */
---
>  struct dirent result;        /* For readdir_r */
181c181
<         while ((dirbuf = (struct dirent *) readdir_r(dp, (struct dirent
*)result)))
---
>         while ((dirbuf = (struct dirent *) readdir_r(dp, &result)))
183c183
<         while (readdir_r(dp, (struct dirent *)result, &dirbuf) == 0)
---
>         while (readdir_r(dp, &result, &dirbuf) == 0)

---------------------------------------------------------
 
The "dirent" structure on SUN doesn't contain memory space for filenames:
typedef struct dirent {
 ino_t  d_ino;  /* "inode number" of entry */
 off_t  d_off;  /* offset of disk directory entry */
 unsigned short d_reclen; /* length of this record */
 char  d_name[1]; /* name of file */
} dirent_t;

so the caller us responsible to allocate enough memory for the "d_name"
field.
 
WBR
--
 
Gregory E. Moltchadski
Senior Software Engineer
 
ATCSim GmbH
Carl-Zeiss-Strasse 41
55129 Mainz
Germany
 
Tel:   +49 (0)6131 250 533 31
Fax:   +49 (0)6131 250 533 40
Mobil: +49 (0)177  653 2998