Re: cc optimisation levels ?

Graeme Lee reported no data returned from squid on openbsd 2.8. I have openBSD 2.7 & had just upgraded to 2.8, just after upgrading
I ran into a problem, which I hadn't tracked down.

I suspected it mightbe the same, so I asked grame for a bt from the squid.core if one was created:

It was the same problem as mine. - but I'm currently waiting confirmation from Graeme before I report the O level consistently
fixing it - so this is a little premature.

I looked at the code and couldn't see anything wrong with rfc1035NamePack & rfc1035QuestionPack. I rebuilt rfc1035.c with O1 and
updated the library, relinked squid and voila the problem was gone.

> Would be quite a mess to maintain, and if the compiler is found to fail
> on one file, how does you know that it doesn't produce similar errors in
> other files? It is not like we have an extensive test suite that makes
> sure each line of code is tested...

But we do have a large user base that is likely to appreciate the ?increased? performance and report problems.

== the start of my dmesg ==
OpenBSD 2.8 (GENERIC) #399: Mon Nov 6 10:59:23 MST 2000
    deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: F00F bug workaround installed
cpu0: Intel Pentium (P54C) ("GenuineIntel" 586-class) 150 MHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8
real mem = 100249600 (97900K)
avail mem = 87871488 (85812K)

=== ggc -v ===
Reading specs from /usr/lib/gcc-lib/i386-unknown-openbsd2.8/2.95.3/specs
gcc version 2.95.3 19991030 (prerelease)

== faulty cmd line
gcc -g -O2 -Wall -I../include -I../../squid/include -c ../../squid/lib/rfc1035.c
=== working cmd line
gcc -g -O1 -Wall -I../include -I../../squid/include -c ../../squid/lib/rfc1035.c

== symptoms
The hostname parameter from rfc1035BuildAQuery reached rfc1035QuestionPack as a NULL pointer when O2 is used in that environment.

=== graeme's bt ===
(gdb) bt
#0 0x400fb6a8 in strdup ()
#1 0x71428 in rfc1035NamePack (buf=0x4b940c "", sz=500, name=0x0)
    at rfc1035.c:176
#2 0x714f2 in rfc1035QuestionPack (buf=0x4b940c "", sz=500, name=0x0,
type=1,
    class=1) at rfc1035.c:201
#3 0x71e42 in rfc1035BuildAQuery (hostname=0x4b14e0 "www.omni.net.au",
    buf=0x4b9400 "", szp=0x4b9600) at rfc1035.c:480
#4 0x23c0e in idnsALookup (name=0x4b14e0 "www.omni.net.au",
    callback=0x4042c <ipcacheHandleReply>, data=0x4b1500) at
dns_internal.c:480
#5 0x40a0b in ipcache_nbgethostbyname (name=0x494888 "www.omni.net.au",
    handler=0x1bfe8 <commConnectDnsHandle>, handlerData=0x4955c0)
    at ipcache.c:500
#6 0x1bf1b in commConnectStart (fd=15, host=0x494888 "www.omni.net.au",
    port=80, callback=0x2670c <fwdConnectDone>, data=0x495580) at
comm.c:237
#7 0x26c9d in fwdConnectStart (data=0x495580) at forward.c:271
#8 0x26d09 in fwdStartComplete (servers=0x4b14a0, data=0x495580)
    at forward.c:281
#9 0x4bad0 in peerSelectCallback (psstate=0x4aff00) at peer_select.c:198
#10 0x4bec2 in peerSelectFoo (ps=0x4aff00) at peer_select.c:281
#11 0x4b8d8 in peerCheckAlwaysDirectDone (answer=1, data=0x4aff00)
    at peer_select.c:173
#12 0x65c5 in aclCheckCallback (checklist=0x4bc000, answer=ACCESS_ALLOWED)
    at acl.c:1653
---Type <return> to continue, or q <return> to quit---
#13 0x6428 in aclCheck (checklist=0x4bc000) at acl.c:1613
#14 0x68ae in aclNBCheck (checklist=0x4bc000,
    callback=0x4b880 <peerCheckAlwaysDirectDone>, callback_data=0x4aff00)
    at acl.c:1763
#15 0x4bdda in peerSelectFoo (ps=0x4aff00) at peer_select.c:252
#16 0x4b7c3 in peerSelect (request=0x494800, entry=0x4a5f40,
    callback=0x26cbc <fwdStartComplete>, callback_data=0x495580)
    at peer_select.c:153
#17 0x2750c in fwdStart (fd=14, e=0x4a5f40, r=0x494800) at forward.c:478
#18 0x19250 in clientProcessMiss (http=0x4b9000) at client_side.c:2057
#19 0x18fc1 in clientProcessRequest (http=0x4b9000) at client_side.c:1996
#20 0x141dc in clientRedirectDone (data=0x4b9000, result=0x0)
    at client_side.c:299
#21 0x4e1aa in redirectStart (http=0x4b9000,
    handler=0x13f74 <clientRedirectDone>, data=0x4b9000) at redirect.c:103
#22 0x13d9d in clientAccessCheckDone (answer=1, data=0x4b9000)
    at client_side.c:215
#23 0x65c5 in aclCheckCallback (checklist=0x4b2f00, answer=ACCESS_ALLOWED)
    at acl.c:1653
#24 0x6428 in aclCheck (checklist=0x4b2f00) at acl.c:1613
#25 0x68ae in aclNBCheck (checklist=0x4b2f00,
    callback=0x13cc8 <clientAccessCheckDone>, callback_data=0x4b9000)
    at acl.c:1763
---Type <return> to continue, or q <return> to quit---
#26 0x13b16 in clientAccessCheck (data=0x4b9000) at client_side.c:162
#27 0x1ad02 in clientReadRequest (fd=14, data=0x4b2d00) at
client_side.c:2534
#28 0x1e9b6 in comm_poll (msec=0) at comm_select.c:437
#29 0x43731 in main (argc=2, argv=0xdfbfdcfc) at main.c:698
===

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>
Sent: Sunday, January 21, 2001 12:46 AM
Subject: Re: cc optimisation levels ?

> Robert Collins wrote:
> >
> > I've just tracked down the problem reported by Grame on thursday
> > to squid users on openbsd 2.8 as a -O2 issue with rfc1035.c
>
> Details please:
> * Processor
> * Compiler, version, patchlevel
> * Compiler flags used
> * Symptoms
>
> > Is there anything we can do in the code to allow higher
> > optimisation levels?
>
> Not much besides
> a) When it is our fault, fix the code
> b) When it is the compilers fault, either fix the compiler or change our
> code to work around the bug.
>
> > I think we should only pull the O level down for files that break -
> > no need to reduce efficiency on the whole package.
>
> Would be quite a mess to maintain, and if the compiler is found to fail
> on one file, how does you know that it doesn't produce similar errors in
> other files? It is not like we have an extensive test suite that makes
> sure each line of code is tested...
>
> /Henrik
>
>
Received on Sat Jan 20 2001 - 14:53:56 MST