screwy NULL on Solaris

screwy NULL on Solaris

Post by Phil Curr » Thu, 08 Nov 2001 15:25:44



Help-
I got my lab all done and running like a charm at home (bsd/darwin/gcc) only
to have it bus error/core dump at school. After an eternity I've narrowed it
down to this:

I test a pointer to a struct for NULL and it refuses to recognize the NULL
which by the way prints out with different values. Sometimes 0x0 or 0x1 or
0x100, etc.

while ( walker != NULL )
{
   if ( strcmp ( hsn->hashStr, walker->hashStr ) )
   {
      hsn->hashStr = walker->hashStr;
      return hsn;
   } /* end if */

   printf("\nwalk: %p, walkColl: %p\n", walker, walker->hCollision);
   walker = walker->hCollision;

Quote:} /* end while */

Even after walker has taken on a value of NULL from walker->hCollision the
while loop executes again and craps out at the printf.

Please help me see the error of my ways.
Thanks.
-Phil
--
AMBITION - a poor excuse for not having enough sense to be lazy.

 
 
 

screwy NULL on Solaris

Post by Paul Pluzhniko » Thu, 08 Nov 2001 16:12:59



Quote:> Even after walker has taken on a value of NULL from walker->hCollision the
> while loop executes again and craps out at the printf.

Clearly this is impossible, unless someone modifies
walker->hCollision after printf() but before the
walker = walker->hCollision assignment.

Quote:> Please help me see the error of my ways.

There doesn't appear to be anything wrong with
the code you posted, so the problem must be in
the code you didn't post ;-)

Two ways I can think of for your code to be broken:
- walker is pointing at free()d memory or to an
  automatic storage location which has been poped off stack.

- there is more than 1 thread and walker is shared
  between them without proper locking.

 
 
 

screwy NULL on Solaris

Post by Stephen Bayne » Thu, 08 Nov 2001 21:44:13



> I test a pointer to a struct for NULL and it refuses to recognize the NULL
> which by the way prints out with different values. Sometimes 0x0 or 0x1 or
> 0x100, etc.

That does not sound like a NULL. I don't know solaris specifically - but
I would expect NULL to print only as 0x0. That is the normal practice on Unix
machines (and is also so on most (but not guarenteed to be so on all) machines, Unix or otherwise).

--

Philips Semiconductors Ltd                  
Southampton SO15 0DJ                        +44 (0)23 80316431
United Kingdom                              My views are my own.

 
 
 

screwy NULL on Solaris

Post by Rich Tee » Fri, 09 Nov 2001 02:00:24



> I test a pointer to a struct for NULL and it refuses to recognize the NULL
> which by the way prints out with different values. Sometimes 0x0 or 0x1 or
> 0x100, etc.

On Solaris, the first several MB are "NULL" as far as trapping NULLs
are concerened, but NULL itself expands to just one value (typically
(void *) 0).

0x100 obviously isn't 0x0, which is why the while loop test doesn't
work how you intend it to.  in other words, a pointer to 0x100 isn't
NULL when testing for equivelence to 0x0 (NULL), but as fars as the
run time system is concerned, it is NULL, hence you get a SIGSEGV.

As to WHAT is actually causing your root problem, I don't know.

--
Rich Teer

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

 
 
 

screwy NULL on Solaris

Post by Casper H.S. Dik - Network Security Engine » Fri, 09 Nov 2001 03:21:42


[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]


>On Solaris, the first several MB are "NULL" as far as trapping NULLs
>are concerened, but NULL itself expands to just one value (typically
>(void *) 0).

For tiny values of "MB" (the first 64K for 32 bit processes)

As for you rproblem, it sounds most like using unitialized data
(data returned from malloc or on the satck doe snot read as all-zero)

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

screwy NULL on Solaris

Post by Benjamin Kaufma » Fri, 09 Nov 2001 09:36:32


NULL is 0x0, not 1 or any other  value.  You've got a bug, NULL is not screwy.
Bugs don't always express themselves consistantly on different machines.

Ben


>Help-
>I got my lab all done and running like a charm at home (bsd/darwin/gcc) only
>to have it bus error/core dump at school. After an eternity I've narrowed it
>down to this:

>I test a pointer to a struct for NULL and it refuses to recognize the NULL
>which by the way prints out with different values. Sometimes 0x0 or 0x1 or
>0x100, etc.

>while ( walker != NULL )
>{
>   if ( strcmp ( hsn->hashStr, walker->hashStr ) )
>   {
>      hsn->hashStr = walker->hashStr;
>      return hsn;
>   } /* end if */

>   printf("\nwalk: %p, walkColl: %p\n", walker, walker->hCollision);
>   walker = walker->hCollision;

>} /* end while */

>Even after walker has taken on a value of NULL from walker->hCollision the
>while loop executes again and craps out at the printf.

>Please help me see the error of my ways.
>Thanks.
>-Phil

 
 
 

screwy NULL on Solaris

Post by Phil Curr » Sat, 10 Nov 2001 00:26:44


Well... it's kind of embarrassing. When I malloc'ed the structure 'walker' I
actually malloc'ed a ptr to the structure and that was eventually showing up
in the situation that Rich Teer described above. Thanks for all the
responses. Bugs sure have a way of popping their heads up in peculiar ways!

-Phil
--
Hard work often pays off after time, but laziness always pays off now.

----------


> Help-
> I got my lab all done and running like a charm at home (bsd/darwin/gcc) only
> to have it bus error/core dump at school. After an eternity I've narrowed it
> down to this:

> I test a pointer to a struct for NULL and it refuses to recognize the NULL
> which by the way prints out with different values. Sometimes 0x0 or 0x1 or
> 0x100, etc.

> while ( walker != NULL )
> {
>    if ( strcmp ( hsn->hashStr, walker->hashStr ) )
>    {
>       hsn->hashStr = walker->hashStr;
>       return hsn;
>    } /* end if */

>    printf("\nwalk: %p, walkColl: %p\n", walker, walker->hCollision);
>    walker = walker->hCollision;

> } /* end while */

> Even after walker has taken on a value of NULL from walker->hCollision the
> while loop executes again and craps out at the printf.

> Please help me see the error of my ways.
> Thanks.
> -Phil
> --
> AMBITION - a poor excuse for not having enough sense to be lazy.

 
 
 

screwy NULL on Solaris

Post by Paul Flo » Sat, 10 Nov 2001 19:01:08


On 7 Nov 2001 18:21:42 GMT, Casper H.S. Dik - Network Security Engineer

>[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]


>>On Solaris, the first several MB are "NULL" as far as trapping NULLs
>>are concerened, but NULL itself expands to just one value (typically
>>(void *) 0).

>For tiny values of "MB" (the first 64K for 32 bit processes)

>As for you rproblem, it sounds most like using unitialized data
>(data returned from malloc or on the satck doe snot read as all-zero)

Or inadvertently casting an int to a pointer. e.g.

int x = 10;
scanf("%d", x);

A bientot
Paul
--
Dr. Paul Floyd       Silvaco Grenoble Research Centre
55, rue Blaise Pascal, ZIRST II, 38330, Montbonnot St. Martin, France
www.silvaco.com      Tel: +33 (0)4 56 38 10 34

 
 
 

1. Solaris 9 Gnome clock applet shows screwy time

As I type this, the actual date and time is

    Wed Mar  3 14:58:56 EST 2004

but my Gnome clock applet is showing me

    Tue Feb 10 03:14:34

My TZ variable is set to EST5EDT in my startup files, though the
system time is kept in GMT.  There is definitely no problem with my
system time:

    $ ntpdate -q tick.usno.navy.mil
    server 192.5.41.40, stratum 1, offset -0.051772, delay 0.19289
     3 Mar 15:01:46 ntpdate[20347]: adjust time server 192.5.41.40
                offset -0.051772 sec

If I go to "Preferences..." and change the time to UTC, the Gnome
applet shows the correct UTC time and date.  If I change to "UNIX
time" it shows the correct seconds-since-the-Epoch value.  Even
"Internet time" is correct.  But if I have it show the regular time it
goes back to being exactly 22 days, 11 hours, 44 minutes and 22
seconds behind the correct time.  This offset seems to be constant.

I am mystified as to why this should be so, as well as how to
troubleshoot the problem.  Any suggestions?
--
  _+_ From the catapult of |If anyone disagrees with any statement I make, I
_|70|___:)=}- J.D. Baldwin |am quite prepared not only to retract it, but also

***~~~~-----------------------------------------------------------------------

2. set user id and set group id bits

3. stat.h screwy in gcc-2.5.0 on Solaris x86 2.1

4. Shutting Down

5. Colors are screwy when run fvwm2 on Solaris 7 with 24-bit TrueColor

6. Print from KDE

7. suspect list_empty( {NULL, NULL} )

8. usb-storage log verbosity

9. HELP: 2>&1 > /dev/null != 2>&- > /dev/null ???

10. pccardd[49]: No card in database for "(null)"("(null)")

11. setvbuf (logfile, NULL, _IOLBF, NULL) in a separate function

12. cp /dev/null or cat /dev/null

13. PROBLEM: ioremap returning NULL and non-NULL for the same high memory adresses