From: Grant Grundler <grundler@dsl2.external.hp.com>
To: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
Cc: willy@debian.org, carlos@baldric.uwo.ca,
parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] malloc limits
Date: Sat, 21 Sep 2002 16:33:52 -0600 [thread overview]
Message-ID: <20020921223352.C64324829@dsl2.external.hp.com> (raw)
In-Reply-To: Message from "John David Anglin" <dave@hiauly1.hia.nrc.ca> of "Sat, 21 Sep 2002 01:24:54 EDT." <200209210524.g8L5OtNw006246@hiauly1.hia.nrc.ca>
"John David Anglin" wrote:
> It's the address of the next contiguous chunk. This is roughly the sum
> of the address plus the size of the chunk to be freed. The segv occurs
> loading the size of the next chunk using the address.
I'll assume this is happening on the A500 (PA2.0) and wonder if it's
a signed/unsigned bug. Look closely at how PA2.0 extends register
values and make sure code is treating addresses and sizes as unsigned.
> I haven't been successful debugging the code directly. I can get the
> code to seg fault by setting SIG37 to nostop noprint, but the debugger
> seems to think the fault occurs following the INLINE_SYSCALL in
> __sigsuspend. However, the address points to an ldi instruction
> which can't seg fault, so I don't know what's up.
Not all instructions trap precisely. FP ops definitely do not and
I thought a few others didn't either.
I'm wondering what happens when unaligned access should segfault.
Does the unaligned code handle check for that?
I'll take a quick look at that code path.
thanks,
grant
next prev parent reply other threads:[~2002-09-21 22:33 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200209190805.KAA0000032531@simba.sch.bme.hu>
2002-09-19 9:17 ` [parisc-linux] SMP kernel problems on a D350 Istvan Gyenes
2002-09-19 12:21 ` J.Steindlberger
2002-09-19 12:29 ` Ryan Bradetich
2002-09-19 22:46 ` Grant Grundler
2002-09-20 8:28 ` Istvan Gyenes
2002-09-20 19:48 ` Carlos O'Donell
2002-09-20 20:02 ` Jeremy Drake
2002-09-20 20:37 ` Carlos O'Donell
2002-09-20 20:46 ` John David Anglin
2002-09-20 20:50 ` Randolph Chung
2002-09-20 20:55 ` Carlos O'Donell
2002-09-21 23:20 ` Randolph Chung
2002-09-22 0:57 ` Grant Grundler
2002-09-20 20:55 ` John David Anglin
2002-09-20 21:51 ` Randolph Chung
2002-09-21 3:38 ` [parisc-linux] malloc limits John David Anglin
2002-09-21 4:14 ` Matthew Wilcox
2002-09-21 4:46 ` Grant Grundler
2002-09-21 5:24 ` John David Anglin
2002-09-21 22:33 ` Grant Grundler [this message]
2002-09-22 5:43 ` John David Anglin
2002-09-20 20:37 ` [parisc-linux] SMP kernel problems on a D350 Bdale Garbee
2002-09-20 20:52 ` Carlos O'Donell
2002-09-20 23:11 ` Jeremy Drake
2002-09-20 23:46 ` Jeremy Drake
2002-09-20 23:55 ` Robert Stanford
2002-09-21 4:31 ` Grant Grundler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020921223352.C64324829@dsl2.external.hp.com \
--to=grundler@dsl2.external.hp.com \
--cc=carlos@baldric.uwo.ca \
--cc=dave@hiauly1.hia.nrc.ca \
--cc=parisc-linux@lists.parisc-linux.org \
--cc=willy@debian.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.