Bugzilla

Updated

•

25 years ago

Assignee: leger → radha

Component: Browser-General → XPApps

Radha on family leave (not reading bugmail)

Comment 1

•

25 years ago

history, radha.

Updated

•

25 years ago

Assignee: radha → leger

Radha on family leave (not reading bugmail)

Comment 2

•

25 years ago

I do only session History, BAck/Forward buttons. This is the global history
window. Stack trace suggests something in XUL/CSS or some date/time calculation
for history entries. waterson or evaughan may be able to help. Reassigning to
leger.

leger

Updated

•

25 years ago

Assignee: leger → pierre

Component: XPApps → Style System

QA Contact: leger → chrisd

leger

Comment 3

•

25 years ago

Sengind over to Gecko guys to check out.

Pierre Saslawsky

Updated

•

25 years ago

Assignee: pierre → waterson

Pierre Saslawsky

Comment 4

•

25 years ago

I can't reproduce it on recent builds on Mac and Windows. Reassigning to waterson
who seemed to have worked on History and who is more likely to have a Unix box.

Christine Hoffman

Updated

•

25 years ago

QA Contact: chrisd → tever

Updated

•

25 years ago

Status: NEW → ASSIGNED

Priority: P3 → P1

Target Milestone: M13

Comment 5

•

25 years ago

hey mcafee, can you help me with this one? i've managed to reproduce it: it's
solaris-only, and is dying in the bowels of NSPR's date conversion routines.
I've managed to trap in in gdb, and everything looks sane, so I have no idea
why we're getting a segfault.

Updated

•

25 years ago

Summary: Crash when attempting to open the History window → Solaris: Crash when attempting to open the History window

Comment 6

•

25 years ago

waterson, I can help look at this, updating my build now.

Comment 7

•

25 years ago

ok, i tried building this with both gcc-2.7.2.3 and egcs-1.1.2. I was only able
to reproduce the crash-on-open with gcc-2.7.2.3. I'm going to check in a fix
for 22294 (which may be related), and then re-try both platforms.

Updated

•

25 years ago

Summary: Solaris: Crash when attempting to open the History window → Solaris/gcc-2.7.2.3: Crash when attempting to open the History window

Comment 8

•

25 years ago

wan-teh, are there any known problems with LL_L2I() on gcc-2.7.2.3/solaris?

Wan-Teh Chang

Comment 9

•

25 years ago

No, I don't know of any problem with LL_L2I()
on gcc-2.7.2.3/solaris.  This macro expands
to:
    i = (PRInt32) l;

I could see you may have problems due to
truncation, but I don't understand how
you would crash in an assignment statement.

Bruce Mitchener

Updated

•

25 years ago

Component: Style System → Threading

Bruce Mitchener

Comment 10

•

25 years ago

0xef3415c4 <ComputeGMT+36>:     clr  %o0
0xef3415c8 <ComputeGMT+40>:     or  %o1, 0x240, %o1
0xef3415cc <ComputeGMT+44>:     std  %o0, [ %fp + -88 ]
0xef3415d0 <ComputeGMT+48>:     ldd  [ %fp + -24 ], %o0
0xef3415d4 <ComputeGMT+52>:     ldd  [ %fp + -88 ], %o2
0xef3415d8 <ComputeGMT+56>:
call  0xef375d28 <_PROCEDURE_LINKAGE_TABLE_+2652>
0xef3415dc <ComputeGMT+60>:     nop
0xef3415e0 <ComputeGMT+64>:     std  %o0, [ %fp + -72 ]
0xef3415e4 <ComputeGMT+68>:     ldd  [ %fp + -24 ], %o2
0xef3415e8 <ComputeGMT+72>:     mov  %o2, %o0
0xef3415ec <ComputeGMT+76>:     mov  %o3, %o1
0xef3415f0 <ComputeGMT+80>:     ldd  [ %fp + -88 ], %o2
---Type <return> to continue, or q <return> to quit---
0xef3415f4 <ComputeGMT+84>:
call  0xef375d34 <_PROCEDURE_LINKAGE_TABLE_+2664>
0xef3415f8 <ComputeGMT+88>:     nop
0xef3415fc <ComputeGMT+92>:     std  %o0, [ %fp + -80 ]
0xef341600 <ComputeGMT+96>:     ld  [ %fp + 0x4c ], %o0
0xef341604 <ComputeGMT+100>:    ld  [ %fp + -76 ], %o1
0xef341608 <ComputeGMT+104>:    st  %o1, [ %o0 ]

It crashes there in 0xef321608 at the store statement.  At that point in time,
the o1 and o0 registers are:

o0             0xef342c64       -281793436
o1             0xa88a4           690340

And:
(gdb) print gmt
$1 = (PRExplodedTime *) 0xef342c64
(gdb) print &usec
$2 = (long long int *) 0xefffaa30
(gdb) print usec
$3 = 690340
(gdb) print *gmt
$4 = {tm_usec = -1646018768, tm_sec = -536371136, tm_min = -265838524,
  tm_hour = 318767188, tm_mday = -1877843584, tm_month = -802701380,
  tm_year = -28665, tm_wday = -65 '¿', tm_yday = -28153, tm_params = {
    tp_gmt_offset = 1073794098, tp_dst_offset = 16777216}}
(gdb)

Hope that helps a bit.

Wan-Teh Chang

Comment 11

•

25 years ago

I looked at the sparc assembly and variable values
that bruce obtained from the debugger.  I am not
familiar with sparc assembly, but I don't see anything
wrong.

Come to think of it, NSPR did not define HAVE_LONG_LONG
for Solaris before.  I was told that the reason was that
gcc did not support long long.  I don't know which version
of gcc that was and whether gcc didn't have the long long
type or had a buggy implementation of long long stuff.

Comment 12

•

25 years ago

okay, i think the problem is that we're invoking the compiler differently
between NSPR and the rest of the browser source tree. The way that C++ is
passing long-long's as parameters is not how NSPR is expecting it. so the
parameters are being munged on the way in to PR_ExplodeTime().

Comment 13

•

25 years ago

Doh! In the C++ code, sizeof(PRTime) == 4. In NSPR, sizeof(PRTime) == 8. Oops.

Comment 14

•

25 years ago

sonofabitch. it's the "-pedantic" option.

#include <stdio.h>
int main(int argc, char* argv)
{
    long long foo;
    printf("%d\n",
sizeof(foo)); return 0;
}

compile that with gcc-2.7.2.3, once with "-pedantic", once without. The
program's output will be "4" and "8", respectively.

Moral of the story: don't use "-pedantic" with gcc-2.7.2.3.

Updated

•

25 years ago

Assignee: waterson → cls

Status: ASSIGNED → NEW

Summary: Solaris/gcc-2.7.2.3: Crash when attempting to open the History window → Solaris + gcc-2.7.2.3 + -pedantic creates bad bits b/c of "long long"

Comment 15

•

25 years ago

cls: i'm gonna give this bug to you: you can either mark it as INVALID, or
figure out some way to bulletproof "configure" to keep people from shooting
themselves in the foot. thanks!

Updated

•

25 years ago

Target Milestone: M13

Comment 16

•

25 years ago

clear M13 TFV

Comment 17

•

25 years ago

*** Bug 23359 has been marked as a duplicate of this bug. ***

Updated

•

25 years ago

Target Milestone: M13

Comment 18

•

25 years ago

Ugh. Actually, this is kind of a big deal. I thought that -pedantic was only
turned on if you said "--enable-pedantic". It looks like it is -always- on for
gcc-2.7.2.3. So, this pretty much needs to be done for M13. Adding leaf to cc
list in case cls can't get to this...

Assignee

Updated

•

25 years ago

Status: NEW → ASSIGNED

Assignee

Comment 19

•

25 years ago

Well, I was trying to find out if the proposed check would work on 64 bit machines like an alpha.  I was under the possible misconception that sizeof(long) == sizeof(long long) == 8 on the alpha.  I may have to an another conditional to the patch...&& sizeof(long) != 8.

Assignee

Comment 20

•

25 years ago

Attached patch Adds a runtime check to see if sizeof(long) == sizeof(long long) if using -pedantic — Details — Splinter Review

Wan-Teh Chang

Comment 21

•

25 years ago

You only need to check whether sizeof(long long) == 8.
The size of long is irrelevant to this bug.

It is true that sizeof(long long) == sizeof(long) == 8
on 64-bit systems such as Alpha.  This is called the LP64
model (meaning longs and pointers are 64-bit).

Assignee

Comment 22

•

25 years ago

Attached patch Check for sizeof(long long) == 8 instead. — Details — Splinter Review

Assignee

Comment 23

•

25 years ago

I don't have gcc 2.7.2.3 on my solaris box, so if someone would check that this
properly halts the configure process with an error message, I'll check the patch
in.

Comment 24

•

25 years ago

cls: i just tried this patch, and it claimed that gcc-2.7.2.3 did -not- have
the bug (and thus, configured it to build with -pedantic *on*). can I make
"configure" run verbosely so I can watch what it's trying to do?

Comment 25

•

25 years ago

ok, shaver pointed me to config.log. It doesn't appear to be adding the
"-pedantic" to the CFLAGS before running:

configure:9158: checking whether compiler has -pedantic long long bug
configure:9169: gcc -o conftest  -g  -pedantic   conftest.c -lw -lposix4 -lintl
-lelf -lnsl -lsocket -lresolv -ldl -lm  1>&5
configure: In function `main':
configure:9165: warning: ANSI C does not support `long long'
configure:9213: checking whether compiler supports -Wno-long-long
configure:9222: gcc -c  -g -Wno-long-long  conftest.c 1>&5
cc1: Invalid option `-Wno-long-long'
configure: failed program was:
#line 9215 "configure"
#include "confdefs.h"

int main() {
return(0);
; return 0; }

Comment 26

•

25 years ago

Oh, I am an idiot. It's right there. Duh. Ok, let me poke around a bit more...

Comment 27

•

25 years ago

Ok, I see the problem. AC_TRY_RUN() is invoking gcc as "gcc", which correctly
notes that sizeof(long long) == 8. If I try to compile the file BY HAND using
"c++", I get sizeof(long long) == 4.

Comment 28

•

25 years ago

FWIW, at Netscape,

% which c++
/tools/contrib/gcc-2.7.2.3/bin/c++
% c++ -v
Reading specs from
/tools/contrib/gcc-2.7.2.3/lib/gcc-lib/sparc-sun-solaris2.6/2.7.2.3/specs

Interestingly, invoking as "g++" gets it right (i.e., sizeof(long long) == 8).
I'm way confused now.

Comment 29

•

25 years ago

cls: i have no idea if this is sane or not, but adding:

  _SAVE_CC=$CC
  CC=$CXX
  /* ...the rest of the goop... */
  CC=$_SAVE_CC

Seems to get AC_TRY_RUN() to do the right thing.

Comment 30

•

25 years ago

Oh, and one more thing: when you check this in, you will instantly break
wensleydale (unless someone has already added --disable-pedantic to
wensleydale's .mozconfig).

Assignee

Comment 31

•

25 years ago

Attached patch 3rd time's a charm. ;-) — Details — Splinter Review

Comment 32

•

25 years ago

looks good to me; r=waterson. just be sure to coordinate with leaf so
wensleydale doesn't burn. thanks, chris!

Comment 33

•

25 years ago

I can also help with watching/fixing wensleydale.

Assignee

Updated

•

25 years ago

Status: ASSIGNED → RESOLVED

Closed: 25 years ago

Resolution: --- → FIXED