Bug 150764 - Startup crash glibc detected free() invalid next size
Startup crash glibc detected free() invalid next size
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anjuta (Show other bugs)
3
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Phillip Compton
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FE4Target FE4Target-x86_64
  Show dependency treegraph
 
Reported: 2005-03-10 07:23 EST by Radu-Adrian Popescu
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-06 08:07:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Radu-Adrian Popescu 2005-03-10 07:23:07 EST
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):
anjuta-1.2.2-6

How reproducible:
Always

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

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

Expected Results:  Start up.

Additional info:

Backtrace:

Program received signal SIGABRT, Aborted.
[Switching to Thread 182894293056 (LWP 30228)]
0x00000034a732e4dd in raise () from /lib64/tls/libc.so.6
(gdb) bt
#0  0x00000034a732e4dd in raise () from /lib64/tls/libc.so.6
#1  0x00000034a732fc8e in abort () from /lib64/tls/libc.so.6
#2  0x00000034a7362b91 in __libc_message () from /lib64/tls/libc.so.6
#3  0x00000034a73684cf in _int_free () from /lib64/tls/libc.so.6
#4  0x00000034a7368a76 in free () from /lib64/tls/libc.so.6
#5  0x0000000000468af4 in compiler_options_new ()
#6  0x00000000004bfbba in anjuta_new ()
#7  0x000000000047dabb in main ()
Comment 1 Dawid Zamirski 2005-03-28 10:06:03 EST
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 11:13:40 EST
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 07:22:13 EST
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.

Cheers,
Comment 4 Pierre Cyr 2005-04-01 08:05:29 EST
Just when I thought I had it going.  I am now experiencing the problem reported
here.

https://www.redhat.com/archives/fedora-extras-list/2005-February/msg00062.html
https://bugzilla.redhat.com/beta/show_bug.cgi?id=147010
(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 17:57:32 EST
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:
https://sourceforge.net/projects/anjuta/ 
Comment 6 Pierre Cyr 2005-04-02 12:37:18 EST
(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
problem.
Comment 7 Pierre Cyr 2005-04-03 15:53:15 EDT
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.)

Cheers,



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.fixed/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 07:48:52 EDT
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 06:18:58 EDT
* 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 06:21:36 EDT
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 17:00:58 EDT
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 08:07:39 EDT
(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 ->
Closing

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