Gtk-CRITICAL assertion g_utf8_validate

[Mario Freimann]

Hello,

I'm running the SOS 4.1 Server on a Win 2000 machine. The SOS 4.1 client is running under Red Hat Enterprise Linux 3 WS. I installed GTK+2.4 from the sources and finally got the SOS client to run.

If I get all files from SourceSafe now, I sometime get the error message in the console window I started SOS from:

(sos:18659): Gtk-CRITICAL **: file gtktextbuffer.c: line 557 (gtk_text_buffer_emit_insert): assertion `g_utf8_validate (text, len, NULL)' failed

On the mono-list I found the following article. Somebody else has a similar problem message:

Hello, Mario.

It looks like you are using gtk-sharp-1.0. It has problems with UTF-8 and TextView widget. gtk-sharp-1.0.2 fixes that problem.

Mario Fuentes wrote:

Hello, I have a problem with sockets, threads and TextView. When a
message is received, I add this to a TextView but in some machine it
crash with this error:

Gtk-CRITICAL **.... (gtk_text_buffer_emit_insert): assertion
'g_utf8_validate (text, len, NULL)' failed.

I don't know if is a Decoding problem (from bytes to string) or a GTK
+/System configuration error.

Attached a use case of the problem.

Bye.

[Skipped]
--
Dmitry Kostenko
.NET Developer


Is this message known, or should I install the 1.0.4?


Regards,

Mario Freimann

[aburnett]

Is this message known, or should I install the 1.0.4?

I've not seen that error before. SOS doesn't use gtk-sharp. What version of the GTK did you compile?

[Mario Freimann]

I compiled gtk+-2.4.14 together with pango-1.4.1, glib-2.4.8 and atk-1.6.1.

Everytime I get a file from sourcesafe, the file name is printed in the SOS client window. But if the message appears the according file name isn't printed. Instead an empty line is inserted into the window ...

[Mario Freimann]

I would be very happy if SourceGear says something to our problems here .. in addition to the mentioned problem we have the following symptoms:

-> On one machine a normal user can't start the SOS client. We get the error message:

Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified


(sos:5877): Gtk-WARNING **: cannot open display:


If I use root the SOS client starts but shows many error messages:

(sos:5745): Gtk-CRITICAL **: file gtkwidget.c: line 4206 (gtk_widget_set_sensitive): assertion `GTK_IS_WIDGET (widget)' failed

-> Another user has the problem that he can't start SOS client at all. There's only one error message:

sos: relocation error: sos: undefined symbol: gtk_window_set_keep_above


The LD_LIBRARY_PATH is set correctly and the library is readable. Furthermore ldd on sos shows that all librarys are available. As I did everything like on the other machine I have no idea why it isn't working ...


As I'm new to Linux I don't know what's going on here. Possibly something went wrong with the compilation with GTK, but making all parts of it went fine and I didn't get any error messages ... we would like to evaluate the product and buy some licenses, but with these errors it isn't possible to evaluate ...


Regards,

Mario Freimann


PS: System is a RedHat Enterprise Linux 3 WS.

[lbauer]

"aburnett" is the developer who updated the Unix clients for SOS 4.1. So if he hasn't seen a particular error, it means we don't have an immediate answer, unfortunately.

Did all the users install SOS as root?

Did you install a particular build of the SOS Unix client or did you build your own client?

[aburnett]

I compiled gtk+-2.4.14 together with pango-1.4.1, glib-2.4.8 and atk-1.6.1.

Everytime I get a file from sourcesafe, the file name is printed in the SOS client window. But if the message appears the according file name isn't printed. Instead an empty line is inserted into the window ...

So this doesn't happen on all files? Is there anything in common with the names of the files when this does occur? Does it happen for all files in a certain project? Any strange characters in the file names?

[aburnett]

I would be very happy if SourceGear says something to our problems here .. in addition to the mentioned problem we have the following symptoms:

PS: System is a RedHat Enterprise Linux 3 WS.

On my Redhat Enterprise 3 WS machine, only libgtk2.2.4 is installed. The new SOS clients need Gtk2.4.x installed to run properly.

[Mario Freimann]

Thanks for your answers!

As the RH machines were in a badly shape because of our wrong installation procedure of the SOS client we installed them from scratch again.

The message
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified


(sos:5877): Gtk-WARNING **: cannot open display:

went away with the help of Google Calling xhost + or xhost +localhost as root added something to the XServer so that the SOS client can connect now.

The message sos: relocation error: sos: undefined symbol: gtk_window_set_keep_above went away as we looked over the LD_LIBRARY_PATH variable. We had inserted /usr/lib before /usr/local/lib so the wrong library was used.

And finally we found out why the error (sos:18659): Gtk-CRITICAL **: file gtktextbuffer.c: line 557 (gtk_text_buffer_emit_insert): assertion `g_utf8_validate (text, len, NULL)' failed occurs:

If a file in SourceSafe has a file name with some kind of German characters (ä, ö, ü, ...) the error occurs. The according file isn't visible inside SOS client at all.

I think this is a serious bug, as the file has the wrong file name after getting it from SourceSafe. Instead of ä, ö or ü there's an ? (instead of Änderungsliste.doc, it is ?nderungsliste.doc). Is this a known bug?


Regards,

Mario Freimann

[lbauer]

If a file in SourceSafe has a file name with some kind of German characters (ä, ö, ü, ...) the error occurs. The according file isn't visible inside SOS client at all.

I think this is a serious bug, as the file has the wrong file name after getting it from SourceSafe. Instead of ä, ö or ü there's an ? (instead of Änderungsliste.doc, it is ?nderungsliste.doc). Is this a known bug?

We have fixed this bug in the Unix client for SOS 4.1.2, but would like to test it further on non-English systems.

Are you an SOS Unix Client user who has encountered this bug?

Do you have accented characters such as ä, ö, ü, etc. in your files?

If so, we'd like to hear from you.

Please email linda at SourceGear.com.