* interesting change
@ 1999-07-30 22:20 Ulrich Drepper
1999-07-30 23:04 ` Thorsten Kukuk
0 siblings, 1 reply; 6+ messages in thread
From: Ulrich Drepper @ 1999-07-30 22:20 UTC (permalink / raw)
To: GNU libc hacker
First, sorry for the broken patch I've added. HJ's malloc patch was
buggy and I haven't tested it before I added it. It should be back to
normal now.
Then, to end the working week I walked into rth's office and
complained about gcc limiting me to write good code. The result: an
hour later we he had a patch which solved the problem. It is now in
the egcs mainline.
The problem to solve was the handling of tables with addresses of
local labels. I introduced this in vfprintf.c. Ever since the data
section was big because of the tables which had to be relocated and
therefore couldn't be made read-only. Also, there were runtime
relocations. This is now gone and the data section is slim again and
startup time got better again.
I hope I got the configure test and the conditionals right. But
you'll certainly let me know.
--
---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: interesting change
1999-07-30 22:20 interesting change Ulrich Drepper
@ 1999-07-30 23:04 ` Thorsten Kukuk
1999-07-30 23:18 ` Ulrich Drepper
0 siblings, 1 reply; 6+ messages in thread
From: Thorsten Kukuk @ 1999-07-30 23:04 UTC (permalink / raw)
To: libc-hacker
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 790 bytes --]
On Fri, Jul 30, Ulrich Drepper wrote:
> First, sorry for the broken patch I've added. HJ's malloc patch was
> buggy and I haven't tested it before I added it. It should be back to
> normal now.
There are some more problems with the your __libc_pagesize optimization.
The list of commercial applications crashing with this patch enlarges
every week.
It seems all of this application uses it's own malloc functions.
The both biggest Applications are StarOffice 5.1 and
CA UniCenter TNG für Linux.
Thorsten
--
Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de
SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg
Linux is like a Vorlon. It is incredibly powerful, gives terse,
cryptic answers and has a lot of things going on in the background.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: interesting change
1999-07-30 23:04 ` Thorsten Kukuk
@ 1999-07-30 23:18 ` Ulrich Drepper
1999-07-30 23:52 ` Thorsten Kukuk
0 siblings, 1 reply; 6+ messages in thread
From: Ulrich Drepper @ 1999-07-30 23:18 UTC (permalink / raw)
To: Thorsten Kukuk; +Cc: libc-hacker
Thorsten Kukuk <kukuk@suse.de> writes:
> There are some more problems with the your __libc_pagesize optimization.
> The list of commercial applications crashing with this patch enlarges
> every week.
> It seems all of this application uses it's own malloc functions.
Well, if they are using their own malloc, how can this be a problem?
The initialization happens at the right time. It can only be that
these application do something forbidden.
--
---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: interesting change
1999-07-30 23:18 ` Ulrich Drepper
@ 1999-07-30 23:52 ` Thorsten Kukuk
1999-07-31 0:00 ` Ulrich Drepper
0 siblings, 1 reply; 6+ messages in thread
From: Thorsten Kukuk @ 1999-07-30 23:52 UTC (permalink / raw)
To: Ulrich Drepper; +Cc: libc-hacker
On Fri, Jul 30, Ulrich Drepper wrote:
> Thorsten Kukuk <kukuk@suse.de> writes:
>
> > There are some more problems with the your __libc_pagesize optimization.
> > The list of commercial applications crashing with this patch enlarges
> > every week.
> > It seems all of this application uses it's own malloc functions.
>
> Well, if they are using their own malloc, how can this be a problem?
> The initialization happens at the right time. It can only be that
> these application do something forbidden.
Maybe our own glibc functins are using our own malloc ?
I only know the following:
- As far as I know all of this software has it's own malloc
- It always crashes in one of our malloc functions
- __libc_pagesize is initialized when it crashes
- If I revert the __libc_pagesize patch all Application works.
- I haven't found a program with source where I could debug it.
My only ideas about this:
1. One of our malloc function was called before the crash in
a way that __libc_pagesize is not set the first time.
2. The application malloc changes pagesize ? (Don't think this
is possible, but ...)
Thorsten
--
Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de
SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg
Linux is like a Vorlon. It is incredibly powerful, gives terse,
cryptic answers and has a lot of things going on in the background.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: interesting change
1999-07-30 23:52 ` Thorsten Kukuk
@ 1999-07-31 0:00 ` Ulrich Drepper
1999-07-31 20:42 ` Geoff Keating
0 siblings, 1 reply; 6+ messages in thread
From: Ulrich Drepper @ 1999-07-31 0:00 UTC (permalink / raw)
To: Thorsten Kukuk; +Cc: libc-hacker
Thorsten Kukuk <kukuk@suse.de> writes:
> 1. One of our malloc function was called before the crash in
> a way that __libc_pagesize is not set the first time.
The value is set in a constructor which runs before any application
code. Except if the application somehow inluences the constructors
which does not only break mallo.c
> 2. The application malloc changes pagesize ? (Don't think this
> is possible, but ...)
No, this is not possible.
--
---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: interesting change
1999-07-31 0:00 ` Ulrich Drepper
@ 1999-07-31 20:42 ` Geoff Keating
0 siblings, 0 replies; 6+ messages in thread
From: Geoff Keating @ 1999-07-31 20:42 UTC (permalink / raw)
To: drepper; +Cc: kukuk, libc-hacker
> Mailing-List: contact libc-hacker-help@sourceware.cygnus.com; run by ezmlm
> List-Unsubscribe: < mailto:libc-hacker-unsubscribe-geoffk=discus.anu.edu.au@sourceware.cygnus.com >
> List-Archive: < http://sourceware.cygnus.com/ml/libc-hacker/ >
> List-Help: < mailto:libc-hacker-help@sourceware.cygnus.com >,
> < http://sourceware.cygnus.com/ml/#faqs >
> Cc: libc-hacker@sourceware.cygnus.com
> Reply-To: drepper@cygnus.com (Ulrich Drepper)
> From: Ulrich Drepper <drepper@cygnus.com>
> Date: 30 Jul 1999 23:56:06 -0700
>
> Thorsten Kukuk <kukuk@suse.de> writes:
>
> > 1. One of our malloc function was called before the crash in
> > a way that __libc_pagesize is not set the first time.
>
> The value is set in a constructor which runs before any application
> code. Except if the application somehow inluences the constructors
> which does not only break mallo.c
It's possible that ld.so has started calling the wrong malloc() again.
There's a short window when ld.so musn't call malloc(), because it
will get the application's malloc before it has run the constructors.
The easiest way to find this is to have a small application:
void *malloc(size_t m)
{
write (STDOUT_FILENO, "malloc called\n", 14);
return 0;
}
void _start(void)
{
write (STDOUT_FILENO, "ok to call malloc after this\n", 29);
_exit(0);
}
--
Geoffrey Keating <geoffk@cygnus.com>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1999-07-31 20:42 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-07-30 22:20 interesting change Ulrich Drepper
1999-07-30 23:04 ` Thorsten Kukuk
1999-07-30 23:18 ` Ulrich Drepper
1999-07-30 23:52 ` Thorsten Kukuk
1999-07-31 0:00 ` Ulrich Drepper
1999-07-31 20:42 ` Geoff Keating
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).