Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 150764 - Startup crash glibc detected free() invalid next size
Summary: Startup crash glibc detected free() invalid next size
Alias: None
Product: Fedora
Classification: Fedora
Component: anjuta
Version: 3
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Phillip Compton
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: FE4Target FE4Target-x86_64
TreeView+ depends on / blocked
Reported: 2005-03-10 12:23 UTC by Radu-Adrian Popescu
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-08-06 12:07:39 UTC

Attachments (Terms of Use)

Description Radu-Adrian Popescu 2005-03-10 12:23:07 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050224 Firefox/1.0.1 Fedora/1.0.1-1.3.1

Description of problem:
Startup crash with glibc/free error:

*** glibc detected *** free(): invalid next size (normal): 0x0000000001002a20 ***

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Start anjuta
2.Witness crash

Actual Results:  *** glibc detected *** free(): invalid next size (normal): 0x0000000001002a20 ***

Expected Results:  Start up.

Additional info:


Program received signal SIGABRT, Aborted.
[Switching to Thread 182894293056 (LWP 30228)]
0x00000034a732e4dd in raise () from /lib64/tls/
(gdb) bt
#0  0x00000034a732e4dd in raise () from /lib64/tls/
#1  0x00000034a732fc8e in abort () from /lib64/tls/
#2  0x00000034a7362b91 in __libc_message () from /lib64/tls/
#3  0x00000034a73684cf in _int_free () from /lib64/tls/
#4  0x00000034a7368a76 in free () from /lib64/tls/
#5  0x0000000000468af4 in compiler_options_new ()
#6  0x00000000004bfbba in anjuta_new ()
#7  0x000000000047dabb in main ()

Comment 1 Dawid Zamirski 2005-03-28 15:06:03 UTC
I also have this problem and it throws the same error messages. The anjta
package for i386 works ok (same version of glibc and anjuta as in x86_64)

Comment 2 Michael Schwendt 2005-03-29 16:13:40 UTC
Running anjuta with MALLOC_CHECK_=0 and/or MALLOC_CHECK_=1 should serve as a
work-around. Inside function compiler_options_new() there is no explicit call of
free(), so memory corruption happens somewhere else. Running anjuta through
valgrind might reveal something.

Comment 3 Pierre Cyr 2005-04-01 12:22:13 UTC
I have a Linux From Scratch (x86_64) and have been experiencing something
similar, so I might be able to help troubleshooting.

I am not writing this from the machine in question, so won't write the full
backtrace I got.  However, (for me) the crash occurs in the populate_supports
function (compiler_options.c) Line 413 (gfree(line);)  populate_supports is
called by compiler_options_new.  The difference in backtrace is probably because
I compiled anjuta with -O0 (for debugging purposes)

First thing I observed is that the memory allocated for "line" is handled by the
call to getline (compiler_options.c:388).  For some reason, the length of the
memory allocated always seems to be 120 (Some lines read from /tmp/anjuta... are
actually more than that)  Could this be a bug in glibc-2.3.4?

Anyhow, to test my theory.  I tried manually allocating memory (only once) to
line ( line = (gchar*)g_malloc(2000); length = 2000; ) and removing all the
"line=NULL;"  I also do the g_free(line); outside the while loop. Anjuta now
starts as expected...

So it does appear to be a glibc bug after all. getline does not work as advertized.


Comment 4 Pierre Cyr 2005-04-01 13:05:29 UTC
Just when I thought I had it going.  I am now experiencing the problem reported
(I did not configure with --enable-final flag)

This is due to the variable "laucher" passed as a null pointer being passed to
anjuta_launcher_scan_output from IA__g_main_context_dispatch.

This would now seem to indicate a glib problem...

I find it indeed weird that anjuta appears to be the only application that
exposes what would be obvious problems.  It's more likely some incidious memory
corruption in Anjuta.  I have noticed several pointers being used as variables
(for data transport through glib/gtk+ functions).

I mean, in a few places, instead of sending a pointer to an integer of a certain
value, they just set the pointer to the actual value, send it through and then
recast it as an integer (pointers and integers aren't exactly the same size on
x86_64).  This is not kosher at all.

Comment 5 Michael Schwendt 2005-04-01 22:57:32 UTC
Re: comment 3

I don't see an obvious mistake in populate_supports().

But while visiting the code sections you referred to, I've filed a bug about
get_a_tmp_file(). IMO it's insecure to create and use predictable tmp file names
like they do.

Re: comment 4

Where you see improper usage of pointers, please file a bug report at: 

Comment 6 Pierre Cyr 2005-04-02 17:37:18 UTC
(In reply to comment #5)
> Re: comment 3
> I don't see an obvious mistake in populate_supports().

I did a little research last night and came across a gentoo patch fixing the
populate_supports() problem.  The problem is that the variable length is
declared as an gint (4 bytes).  Its address is then passed as the second
parameter of getline which is of size_t type (8 bytes long on x86_64).  As a
result the stack becomes corrupted.

--- src/compiler_options.c	2004-04-08 07:21:41.000000000 -0500
+++ src/compiler_options.c	2004-08-24 04:04:46.201104024 -0500
@@ -352,7 +352,7 @@
 	gchar *pkg_cmd;
 	FILE  *pkg_fd;
 	gchar *line;
-	gint   length;
+	size_t   length;
 	GtkTreeIter iter;
 	int i = 0;

As for the other crashes.  They (for me) occur whenever a program is forked in
launcher.c.  I still have not found anything to fix (or actually determine) the

Comment 7 Pierre Cyr 2005-04-03 19:53:15 UTC
So I went through the code and manage to fix the launcher.  Basically it was
another case of stack corruption due to the wrong type variable being passed by
reference.  I saw another faulty getline as well.  Here is the complete patch.
(I'll submit it to the Anjuta developpers as well.)


diff -Naur anjuta-1.2.2/src/about.c anjuta-1.2.2.fixed/src/about.c
--- anjuta-1.2.2/src/about.c    2004-04-08 01:32:05.000000000 -0400
+++ anjuta-1.2.2.fixed/src/about.c      2005-04-02 21:18:23.000000000 -0500
@@ -110,7 +110,7 @@
                GList *node;
                char *line;
                char *utfline;
-               int count;
+               size_t count;

                list = NULL;
                while (!feof(infile) && !ferror (infile))
diff -Naur anjuta-1.2.2/src/compiler_options.c
--- anjuta-1.2.2/src/compiler_options.c 2004-04-08 08:21:41.000000000 -0400
+++ anjuta-1.2.2.fixed/src/compiler_options.c   2005-04-02 20:53:35.000000000 -0500
@@ -352,7 +352,7 @@
        gchar *pkg_cmd;
        FILE  *pkg_fd;
        gchar *line;
-       gint   length;
+       size_t   length;
        GtkTreeIter iter;

        int i = 0;
diff -Naur anjuta-1.2.2/src/launcher.c anjuta-1.2.2.fixed/src/launcher.c
--- anjuta-1.2.2/src/launcher.c 2004-04-08 00:15:31.000000000 -0400
+++ anjuta-1.2.2.fixed/src/launcher.c   2005-04-02 21:30:11.000000000 -0500
@@ -570,7 +570,7 @@
 anjuta_launcher_scan_output (GIOChannel *channel, GIOCondition condition,
                                                         AnjutaLauncher *launcher)
-       int n;
+       gsize n;
        gchar buffer[FILE_BUFFER_SIZE];
        gboolean ret = TRUE;

@@ -618,7 +618,7 @@
 anjuta_launcher_scan_error (GIOChannel *channel, GIOCondition condition,
                                                        AnjutaLauncher *launcher)
-       int n;
+       gsize n;
        gchar buffer[FILE_BUFFER_SIZE];
        gboolean ret = TRUE;

Comment 8 Michael Schwendt 2005-04-04 11:48:52 UTC
Both patches make sense (sizeof(size_t) = sizeof(unsigned long) = 8), and it
would be interesting to get them applied to see what other run-time issues are
found on x86_64.

Comment 9 Michael Schwendt 2005-05-26 10:18:58 UTC
* x86_64 fixes as added upstream in Patches item #1175961 have been applied. The
patches tracker is private now, though.

* Anjuta 1.2.3 was released on 2005-05-15.

Comment 10 Michael Schwendt 2005-07-08 10:21:36 UTC
Please give the update to 1.2.3 a try as soon as it is signed and published in
the repository.

Comment 11 Thomas TROLEZ 2005-08-27 21:00:58 UTC
I think I had the same "bug" with openoffice, my reply on this subject following:

It's because yoyr user isn't into video group. You have two soutions:
-Add your user into video goup
-Add Group video into xorg.conf DRI section as Dave'2005 said.

This probleme caused because user try to acces to DRI node. When you add "Group
video" into xorg.conf, it's put xorg into video group for the current session.

Comment 12 Thorsten Leemhuis 2006-08-06 12:07:39 UTC
(In reply to comment #10)
> Please give the update to 1.2.3 a try as soon as it is signed and published in
> the repository.

I stumbled over this -- no reply in the past year and looks like it was fixed ->

Note You need to log in before you can comment on or make changes to this bug.