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)

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.

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,

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.

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/ 

(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.

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;

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.

* 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.

Please give the update to 1.2.3 a try as soon as it is signed and published in
the repository.

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.

(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