Re: Squid 3.0 Compilation issues on IA64

Hi "GV"

Please use the bugzilla tool when commenting on this issue. There you also
find a short discussion on what the problem is and a suggested fix. The
fix is not yet committed to the sources as you have not commented if the
fix works for you, and it is possible the problem should be fixed in
memFreeString rather than memAllocString..

And no, the line you refer to below is not the cause, only a fact
contributing to why the problem shows up on IA64. The line is required to
make the pool elements properly aligned on cpu word boundary.

Regards
Henrik

On Tue, 27 May 2003, GV wrote:

> 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 - 22:19:20 MDT