From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31297 invoked by alias); 29 Sep 2005 12:38:13 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 30947 invoked by uid 48); 29 Sep 2005 12:37:58 -0000 Date: Thu, 29 Sep 2005 12:38:00 -0000 From: "kostikbel at ukr dot net" To: gcc-bugs@gcc.gnu.org Message-ID: <20050929123754.24120.kostikbel@ukr.net> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug java/24120] New: jc1 incorrectly uses libiberty hashes X-Bugzilla-Reason: CC X-SW-Source: 2005-09/txt/msg03602.txt.bz2 List-Id: (At least ) in gcc/java/jfc-io.c, the memoized_dirlists hash is created by the call htab_create (37, htab_hash_string <-- NOTE THIS, memoized_dirlist_lookup_eq, NULL); Actually, htab contains the structures (memoized_dirlist_entry), not the strings. All went ok until hashtab.c decides it need to expand hash. Then, libiberty/hashtab.c, htab_expand function tries to calculate hashes of hash entries itself, calling htab_hash_string on elements of hash, that are not the strings, but the structures. When this happens, under right conditions jc1 crashes with SIGSEGV. I found this on FreeBSD 6-CURRENT with debug malloc that fills uninitialized storage with 0xd0. The problem is platform independent. It seems that such code is present at least in 3.4.4, 4.0.2 and HEAD. -- Summary: jc1 incorrectly uses libiberty hashes Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kostikbel at ukr dot net CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24120