Re: Squid 3.0 Compilation issues on IA64

Hello Henrik

Looks like, I have identified the cause for the bug 658.

In lib/MemPool.c:

    404 MemPool *
    405 memPoolCreate(const char *label, size_t obj_size)
 ------
< snip >
 ------
    415 pool->obj_size = obj_size;
    416 pool->obj_size =
    417 ((obj_size + sizeof(void *) - 1) / sizeof(void *)) *
sizeof(void *);

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Could you please share your thoughts on this line? Why can't
we just stay with 415 line only? What this second line do?
do we really need this? If this solves the issue, is it possible to make
this code in to
 main CVS?

pool->obj_size becomes 40, due to this statement as opposed to the
value of 36.

((36+8-1)/8)*8 = 40

I have commented out the line 416 & 417, now squid starts properly
without any assertion failed. But I do see the unaligned access
information in cache.log file. Any comments/help will be much
appreciated.

squid(10008): unaligned access to 0x6000000000955ad4, ip=0x4000000000130b31
squid(10008): unaligned access to 0x6000000000955b1c, ip=0x4000000000130b31
squid(10008): unaligned access to 0x6000000000955b64, ip=0x4000000000130b31
squid(10008): unaligned access to 0x6000000000955bac, ip=0x4000000000130b31

For bug 659 - Warning messages for IA64.

Warning messages are due to "%d" printf statements and some of them need
explicit type casting.

What is the best way of solving this issue? So that this fix also can be a
part of main CVS.
Could you please suggest something, I can work on this. Will it IFDEF for
IA64 be the right chioce?

Thank you.

Regards
GV

>
> Hello Henrik,
>
> Bug IDs are 658 and 659 respectively. Please let me know, if you need more
> information on this issue.
>
> Regards,
> GV
>
> > Please open two bug reports.
> >
> > 1. A bug report with the assertion error, and a backtrace of where it
> > happens.
> >
> > 2. A bug report with the warnings.
> >
> > Regards
> > Henrik
> >
> > On Sun, 25 May 2003, GV wrote:
> >
> > > Hello Henrik,
> > >
> > > Thanks for your response. Looks like the problem is more than what I
> thought
> > > off. Please see the details below.
> > >
> > > I fixed all the warnings, most of them are from debug statements and
> just
> > > commented them out. Other warnings and fixes are as follows...
> > >
> > > 1. "HttpReply.cc" - typecast to ssize_t solves this warning
> > >
> > > 161 size_t s = XMIN(end + 1, (ssize_t)4096);
> > > ^^^^^^^
> > > HttpReply.cc: In function `int httpReplyParse (HttpReply *, const char
> *,
> > > long int)':
> > > HttpReply.cc:161: no matching function for call to `min (long int,
int)'
> > >
> > > 2. "mem.cc" - %d to %ld
> > >
> > > cc1plus: warnings being treated as errors
> > > mem.cc: In function `void memBufStats (StoreEntry *)':
> > > mem.cc:125: warning: int format, different type arg (arg 3)
> > > mem.cc:125: warning: int format, different type arg (arg 4)
> > > mem.cc: In function `void Mem::PoolReport (const MemPoolStats *, const
> > > MemPoolMeter *, StoreEntry *)':
> > > mem.cc:622: warning: int format, different type arg (arg 4)
> > > mem.cc:622: warning: int format, different type arg (arg 5)
> > > mem.cc:622: warning: int format, different type arg (arg 9)
> > > mem.cc:622: warning: int format, different type arg (arg 10)
> > > mem.cc:622: warning: int format, different type arg (arg 13)
> > > mem.cc:622: warning: int format, different type arg (arg 14)
> > >
> > > storeAppendPrintf(sentry, "Large buffers: %ld (%ld KB)\n",
> > > 124 HugeBufCountMeter.level,
> > > 125 HugeBufVolumeMeter.level / 1024);
> > >
> > > 598 storeAppendPrintf(e,
> > > 599 "%d\t %ld\t %ld\t %.2f\t %.1f\t" /*
alloc
> */
> > > 600 "%d\t %ld\t %ld\t %.1f\t" /* in use */
> > > 601 "%d\t %ld\t %ld\t" /* idle */
> > > 602 "%.0f\t %.1f\t %.1f\t %.1f\n", /*
saved
> */
> > > 603 /* alloc */
> > > 604 mp_st->items_alloc,
> > >
> > > 3. "stat.c" - %6d to %6ld
> > >
> > > cc1plus: warnings being treated as errors
> > > stat.cc: In function `void info_get (StoreEntry *)':
> > > stat.cc:691: warning: int format, different type arg (arg 3)
> > > stat.cc:693: warning: int format, different type arg (arg 3)
> > >
> > > 690 storeAppendPrintf(sentry, "\tmemPool accounted:
%6ld
> KB
> > > %3d%%\n",
> > > 691 mp_stats.TheMeter->alloc.level >>
10,
> > > percent(mp_stats.TheMet er->alloc.level, t));
> > > 692 storeAppendPrintf(sentry, "\tmemPool unaccounted:
%6ld
> KB
> > > %3d%%\n",
> > > 693 (t - mp_stats.TheMeter->alloc.level)
> >>
> > > 10, percent((t - mp_s tats.TheMeter->alloc.level), t));
> > >
> > > > > Finally, I am NOT quite happy about the hack I did, but works
fine.
> > > > > I did some quick testing with my netscape. Looks better except the
> > > > > above log messages. May be I should fix all the warnings, instead
> > > > > of removing "-Werror" flag from the compilation. If I come up with
> > > > > some changes to make the above issue vanished, will the changes be
> > > > > acceptable to go into CVS?
> > > >
> > > > The warnings should be fixed.
> > >
> > > Please see the above details. As I stated already, other warnings are
> from
> > > debug statements. I can send them, if you need.
> > >
> > > But this[Warning fixes] does NOT solve the runtime issue, I have
> reported
> > > earlier. Still, the assertion is getting failed in the same location.
> > >
> > > 2003/05/25 16:44:08| Starting Squid Cache version 3.0.DEVEL-20030524
for
> > > ia64-unknown-linux-gnu...
> > > 2003/05/25 16:44:08| assertion failed: mem.cc:230: "size ==
> > > StrPoolsAttrs[i].obj_size"
> > > Aborted
> > >
> > > Any help will be much appreciated to proceed further.
> > >
> > > > > Another weired thing I have seen is, regardless of the value I
have
> > > > > set for "mem_pools" "on" or "off", I always have seen "mem_pools
> > > > > are off" in the log file as follows. I am NOT quite sure about
> > > > > this, just wanted to know, if there is a known issue...
> > > > > Log info : Memory pools are 'off'; limit: 0.00 MB
> > > >
> > > > And you did not request to have the pools disabled when you built
your
> > > > Squid? (--disable-mempools)
> > >
> > > I have used only default option with my own prefix. By default,
mempools
> > > should be on, I guess.
> > >
> > > Regards
> > > GV

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
www.ViSolve.net - The Open Source Solutions Provider
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Received on Tue May 27 2003 - 20:40:07 MDT