> gcc wasn't the suspected candidate --- the netbsd guys
> thought it was
> as or ld. On my Fedora machine those seem to be part of
> the binutils
> package; dunno how Debian handles it.
>
Yeah, it appears to be the binutils package on debian too. I have the latest
version from apt, I've checke
Glyn Astill <[EMAIL PROTECTED]> writes:
>> Okay, so it is indeed the linker's fault. Now try plan
>> (a) --- can you
>> find a more up-to-date toolchain?
> Well I've tried looking in apt, and the latest package is the version I've
> got, (the toolchain is more than just gcc isn't it though?) is
>
> Okay, so it is indeed the linker's fault. Now try plan
> (a) --- can you
> find a more up-to-date toolchain?
Well I've tried looking in apt, and the latest package is the version I've got,
(the toolchain is more than just gcc isn't it though?) is there another way to
get a more up to date
Glyn Astill <[EMAIL PROTECTED]> writes:
>> The conclusion of the thread seemed to be that it was a linker or
>> assembler problem triggered by our use of SUBSYS.o files to aggregate
>> all the backend .o files into a smaller number of files for the final
>> link. If so the answer is either (a) upd
> The conclusion of the thread seemed to be that it was a
> linker or
> assembler problem triggered by our use of SUBSYS.o files to
> aggregate
> all the backend .o files into a smaller number of files for
> the final
> link. If so the answer is either (a) update to a newer
> toolchain
> that migh
On 8/6/08, Glyn Astill <[EMAIL PROTECTED]> wrote:
> > Mind you, I'd not especially recommend trying to run CVS HEAD for
> > production purposes, but it would be real interesting at this point
> > to see if you can compile it and run the regression tests with the
> > toolchain you've got.
> >
>
> I'
> Mind you, I'd not especially recommend trying to run CVS HEAD for
> production purposes, but it would be real interesting at this point
> to see if you can compile it and run the regression tests with the
> toolchain you've got.
>
I've no problem doing that, this machine is a toy not a product
[ cc'ing Remi to see if he remembers anything about how he got around this ]
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> FWIW: there also seems to be a fairly indepth discussion on the cobalt
> related netbsd list from last year about a problem that looks very
> similiar (at least to you
Glyn Astill wrote:
http://privatepaste.com/cbY2S4JhtA
Very little difference with the -O0
FWIW: there also seems to be a fairly indepth discussion on the cobalt
related netbsd list from last year about a problem that looks very
similiar (at least to you issue with etch):
http://www.nabble
http://privatepaste.com/cbY2S4JhtA
Very little difference with the -O0
__
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at
Yahoo! http://uk.docs.yahoo.com/ymail/new.ht
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> The trouble with that approach is that it overrides *everything* that
>> configure would normally put into CFLAGS. I only want one thing
>> changing, please ... this is confusing enough already.
> Eh?
Sorry, me
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Tom Lane" <[EMAIL PROTECTED]> writes:
>>> (Rather than trying to browbeat configure into doing this, I'd suggest
>>> manually adjusting CFLAGS in src/Makefile.global, then "make clean" and
>>> rebuild.)
>
>> eh?
> > "Tom Lane" <[EMAIL PROTECTED]> writes:
> >
> > > (Rather than trying to browbeat configure into
> doing this, I'd suggest
> > > manually adjusting CFLAGS in src/Makefile.global,
> then "make clean" and
> > > rebuild.)
> >
> > eh? either of these should work fine:
> >
> > ./configure --enabl
Gregory Stark wrote:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > (Rather than trying to browbeat configure into doing this, I'd suggest
> > manually adjusting CFLAGS in src/Makefile.global, then "make clean" and
> > rebuild.)
>
> eh? either of these should work fine:
>
> ./configure --enable
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> (Rather than trying to browbeat configure into doing this, I'd suggest
>> manually adjusting CFLAGS in src/Makefile.global, then "make clean" and
>> rebuild.)
> eh? either of these should work fine:
> ./configur
"Tom Lane" <[EMAIL PROTECTED]> writes:
> (Rather than trying to browbeat configure into doing this, I'd suggest
> manually adjusting CFLAGS in src/Makefile.global, then "make clean" and
> rebuild.)
eh? either of these should work fine:
./configure --enable-debug CFLAGS=-O0
CFLAGS=-O0 ./configu
Glyn Astill <[EMAIL PROTECTED]> writes:
> Heres a backtrace on a fresh core file
> http://privatepaste.com/911BTjYrY1
> Does this change get us any closer?
Not really ... there's no plausible reason to crash there, either.
Just for entertainment's sake, try recompiling with -O0 instead of the
def
Heres a backtrace on a fresh core file
http://privatepaste.com/911BTjYrY1
Does this change get us any closer?
--- On Tue, 22/7/08, Glyn Astill <[EMAIL PROTECTED]> wrote:
> From: Glyn Astill <[EMAIL PROTECTED]>
> Subject: Re: [GENERAL] Initdb problem on debian mips cobalt: Bu
--- On Tue, 22/7/08, Glyn Astill <[EMAIL PROTECTED]> wrote:
> From: Glyn Astill <[EMAIL PROTECTED]>
> Subject: Re: [GENERAL] Initdb problem on debian mips cobalt: Bus error
> To: "Tom Lane" <[EMAIL PROTECTED]>
> Cc: "Stefan Kaltenbrunner" <[EMAIL PRO
Glyn Astill <[EMAIL PROTECTED]> writes:
> And, the instruction pointer info:
> (gdb) x/i $pc
> 0x7572d0 :
> beqzv0,0x75748c
Huh. The pc could possibly be a bit off from reality in this type of
error, but none of the instructions immediately around it look like they
could be making a
Glyn Astill <[EMAIL PROTECTED]> writes:
>> What ulimit settings are operative anyway? (ulimit -a
>> might tell you)
> deb:/usr/pgsql_src/postgresql-8.3.3/src/test/regress# ulimit -a
> core file size (blocks, -c) 0
Hmm, are you sure the core actually corresponds to your failure?
Because
>
> The stack size rlimit looks normal, which makes a crash in
> this spot
> look even less probable. I think maybe you are looking at
> a stale
> corefile that doesn't quite correspond to this postgres
> executable.
>
You are correct. I just checked and the core file was created on the 18th, t
> The only
> thought that
> comes to mind is that the branch is being attempted but
> there's garbage
> at InitializeGUCOptions+1092 ? Try "x/32i
> InitializeGUCOptions+1092"
>
> What ulimit settings are operative anyway? (ulimit -a
> might tell you)
>
(gdb) x/32i InitializeGUCOptions+1092
0x75
> Well, there's part of your problem: the program that is
> crashing is not
> initdb. Specify the postgres executable, instead. Note
> the
>
> > warning: core file may not match specified executable
> file.
> > Core was generated by
> `/usr/pgsql_src/postgresql-8.3.3/src/test/regress/tmp_check/i
Glyn Astill <[EMAIL PROTECTED]> writes:
> I've just recompiled again after configuring with --enable-debug, and for
> completeness here's all the output from gdb:
> # gdb
> /usr/pgsql_src/postgresql-8.3.3/src/test/regress/tmp_check/install/usr/local/pgsql/bin/initdb
> core
Well, there's part o
>
> Did you actually give a "bt" command, or was that
> just the initial
> output from gdb?
>
Yeah I used the bt command, which gave exactly the same output as the initial
output. However you'll have to bear with me here, as I am new to gdb, so there
is the possibility I'm just not doing thin
Glyn Astill <[EMAIL PROTECTED]> writes:
> A recompile with --enable-debug, then rerunning the make check gave me the
> same backtrace from gdb
Did you actually give a "bt" command, or was that just the initial
output from gdb?
Another thing to try is looking around the current instruction pointe
gt; From: Tom Lane <[EMAIL PROTECTED]>
> To: Glyn Astill <[EMAIL PROTECTED]>
> Cc: Stefan Kaltenbrunner <[EMAIL PROTECTED]>; pgsql-general@postgresql.org
> Sent: Saturday, 19 July, 2008 5:42:30 PM
> Subject: Re: [GENERAL] Initdb problem on debian mips cobalt: Bus er
Glyn Astill <[EMAIL PROTECTED]> writes:
> Would the mips specific code behave differently on different oses?
I'm more worried about there being more than one type of MIPS CPU out
there. Do all qubes contain exactly the same sub-architecture?
The references to "mips2" in s_lock.h are attention-get
> From: Stefan Kaltenbrunner <[EMAIL PROTECTED]>
> Tom Lane wrote:
> > Glyn Astill writes:
> >> No. Will recompile with debug info and post back when done.
> >
> > FWIW, the most likely issue here is the MIPS-specific assembly code in
> > src/include/storage/s_lock.h --- I'm not sure how many MIP
Tom Lane wrote:
Glyn Astill <[EMAIL PROTECTED]> writes:
No. Will recompile with debug info and post back when done.
FWIW, the most likely issue here is the MIPS-specific assembly code in
src/include/storage/s_lock.h --- I'm not sure how many MIPS platforms
that's really been exercised on, but
--- On Fri, 7/18/08, Glyn Astill <[EMAIL PROTECTED]> wrote:
> From: Glyn Astill <[EMAIL PROTECTED]>
> Subject: [GENERAL] Initdb problem on debian mips cobalt: Bus error
> To: pgsql-general@postgresql.org
> Date: Friday, July 18, 2008, 10:26 AM
> Hi Chaps,
>
> I'm attempting to run 8.3.3 on an
Glyn Astill <[EMAIL PROTECTED]> writes:
> No. Will recompile with debug info and post back when done.
FWIW, the most likely issue here is the MIPS-specific assembly code in
src/include/storage/s_lock.h --- I'm not sure how many MIPS platforms
that's really been exercised on, but it may not work on
No. Will recompile with debug info and post back when done.
- Original Message
> From: Tom Lane <[EMAIL PROTECTED]>
> To: Glyn Astill <[EMAIL PROTECTED]>
> Cc: pgsql-general@postgresql.org
> Sent: Friday, 18 July, 2008 5:50:05 PM
> Subject: Re: [GENERAL] In
Glyn Astill <[EMAIL PROTECTED]> writes:
> Could this be any less informative?
> Core was generated by
> `/usr/pgsql_src/postgresql-8.3.3/src/test/regress/tmp_check/install/usr/local/pg'.
> Program terminated with signal 10, Bus error.
> #0 0x007572d0 in ?? ()
Probably not :-(. Did you build wit
gt;
> To: Glyn Astill <[EMAIL PROTECTED]>
> Cc: pgsql-general@postgresql.org
> Sent: Friday, 18 July, 2008 4:01:23 PM
> Subject: Re: [GENERAL] Initdb problem on debian mips cobalt: Bus error
>
> Glyn Astill writes:
> > I'm attempting to run 8.3.3 on an old cobalt qub
Glyn Astill <[EMAIL PROTECTED]> writes:
> I'm attempting to run 8.3.3 on an old cobalt qube, with debian etch. It
> appeared to compile ok (however I didn't stick around to watch, that'd be
> painfull) and said "PostgreSQL compiled successfully and ready to install" or
> whatever, but when I run
18 July, 2008 2:09:28 PM
> Subject: Re: [GENERAL] Initdb problem on debian mips cobalt: Bus error
>
> Glyn Astill wrote:
> > Yes I think it does?
> >
> > deb:/home/glyn# cat /proc/sys/kernel/shmall
> > 2097152
> >
> > deb:/home/glyn# getconf PAGE_SIZE
Glyn Astill wrote:
Yes I think it does?
deb:/home/glyn# cat /proc/sys/kernel/shmall
2097152
deb:/home/glyn# getconf PAGE_SIZE
4096
Well, if it's using PAGE_SIZE then that's 8GB which sounds optimistic
for a qube. Presumably it represents some theoretical maximum.
Did a previous version of
day, 18 July, 2008 12:36:30 PM
> Subject: Re: [GENERAL] Initdb problem on debian mips cobalt: Bus error
>
> Glyn Astill wrote:
> > I assume it's doing it correctly
> >
> > deb:/home/glyn# cat /proc/sys/kernel/shmmax
> > 33554432
> >
> > That'
Glyn Astill wrote:
I assume it's doing it correctly
deb:/home/glyn# cat /proc/sys/kernel/shmmax
33554432
That's right isn't it?
4096*8192= 33554432
Does shmall allow for any more? Other processes may be preventing you
from allocating all that. Of course, ideally you'd get an error message
eneral@postgresql.org
> Sent: Friday, 18 July, 2008 11:48:39 AM
> Subject: Re: [GENERAL] Initdb problem on debian mips cobalt: Bus error
>
> Glyn Astill wrote:
> > Hi Chaps,
> >
> > I'm attempting to run 8.3.3 on an old cobalt qube, with debian etch.
> > It
Glyn Astill wrote:
Hi Chaps,
I'm attempting to run 8.3.3 on an old cobalt qube, with debian etch.
It appeared to compile ok (however I didn't stick around to watch,
that'd be painfull) and said "PostgreSQL compiled successfully and
ready to install" or whatever, but when I run make check, fails
43 matches
Mail list logo
