GNOME Bugzilla – Bug 791973
printf appears to crash when passed too may args
Last modified: 2018-01-17 19:42:35 UTC
Created attachment 365996 [details] Generated C code This commit is now causing my application to crash: https://github.com/steveno/balistica/commit/061a28e98f3c4468b4465e580ada78f11eec4461?diff=unified I don't understand what changed in that commit that breaks the application with my version of Vala versus the one I had on 16.04, but I managed to trace it down to two lines (511 & 513) in src/balistica_application.vala (which aren't changed in the diff !!). If you comment out those two lines it will compile and produce the drag calculation as expected. I also figured out that if you change those two lines so that the printf functions don't format more than two entries, it will also compile and produce the expected output. With a third entry, though, it seg faults trying to print the calculation results. Will Seg Fault: txtViewDragResults.buffer.text += ("Initial Velocity: %.2f ft/s Zero Range: %.2f yards Shooting Angle: %.2f degrees\n").printf (lsln.getMv (), lsln.getZerorange (), lsln.getAngle ()) ; Will print as expected: txtViewDragResults.buffer.text += ("Initial Velocity: %.2f ft/s Zero Range: %.2f yards\n").printf (lsln.getMv (), lsln.getZerorange ()) ; I have attached the C code that is generated.
Could you elaborate "with my version of Vala"? Better use an official vala release or vala git master. Are you able to boil down this problem in a less complex example? Or provide specific steps (input and gui interactions) to reproduce the problem with your application.
Fails to build without: --- a/src/gui/DragBox.vala +++ b/src/gui/DragBox.vala @@ -316,7 +316,7 @@ public class Balistica.DragBox : Gtk.Box { // Create a save as dialog Gtk.FileChooserDialog save_dialog = new Gtk.FileChooserDialog ("Save As", - Application.main_window as Gtk.Window, + ((Application) GLib.Application.get_default ()).main_window as Gtk.Window, Gtk.FileChooserAction.SAVE, "Cancel", Gtk.ResponseType.CANCEL,
I'm using valac 0.36.6 I've spent about an hour or so trying to come up with a minimal example, but I can't seem to reproduce it. I will provide more specific instructions in another message.
@oliver: Please upgrade to a more recent release like 0.36.8
I upgraded to Vala 0.39.4.7-57a54 and it's still crashing for me.
(In reply to oliver.steven from comment #5) > I upgraded to Vala 0.39.4.7-57a54 and it's still crashing for me. Maybe a backtrace would help? If you don't already know: compile with --debug option for valac, start gdb with `gdb ballistica`, then use `run` and when it seg faults, use `bt` to get the backtrace.
@Al Thomas, did not know that. Thank you! Backtrace: Starting program: /home/steveno/Projects/balistica/build/balistica [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffebf88700 (LWP 21829)] [New Thread 0x7fffeb787700 (LWP 21830)] [New Thread 0x7fffead79700 (LWP 21831)] [New Thread 0x7fffe9b4c700 (LWP 21832)] [New Thread 0x7fffe934b700 (LWP 21833)] [Thread 0x7fffe9b4c700 (LWP 21832) exited] Thread 1 "balistica" received signal SIGSEGV, Segmentation fault. 0x00007ffff784f531 in gtk_widget_style_get () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 (gdb) bt
+ Trace 238320
Created attachment 366564 [details] backtrace
I added the backtrace as an attachment because pasting in the comments ended up being a bad idea. Sorry about that.
Hmm, I wasn't expecting that: gtk_widget_style_get () Out of general interest, was the backtrace created with -DCMAKE_BUILD_TYPE=Debug as per https://mail.gnome.org/archives/vala-list/2015-February/msg00004.html ? From your first comment the relevant C code from your first attachment seems to be: _tmp78_ = self->priv->drag_results; _tmp79_ = gtk_text_view_get_buffer (_tmp78_); _tmp80_ = _tmp79_; g_object_get (_tmp80_, "text", &_tmp81_, NULL); _tmp82_ = _tmp81_; _tmp83_ = _tmp82_; _tmp84_ = self->priv->lsln; _tmp85_ = lib_balistica_solution_getMv (_tmp84_); _tmp86_ = self->priv->lsln; _tmp87_ = lib_balistica_solution_getZerorange (_tmp86_); _tmp88_ = self->priv->lsln; _tmp89_ = lib_balistica_solution_getAngle (_tmp88_); _tmp90_ = g_strdup_printf ("Initial Velocity: %.2f ft/s Zero Range: %.2f yards Shooting Angle %." \ "2f degrees\n", _tmp85_, _tmp87_, _tmp89_); _tmp91_ = _tmp90_; _tmp92_ = g_strconcat (_tmp83_, _tmp91_, NULL); _tmp93_ = _tmp92_; g_object_set (_tmp80_, "text", _tmp93_, NULL); _g_free0 (_tmp93_); _g_free0 (_tmp91_); _g_free0 (_tmp83_); The only thing that looks a bit odd if the line continuation breaking up the last %.2f. I'm not sure how that affects things. I've found https://stackoverflow.com/questions/1752079/in-c-can-a-long-printf-statement-be-broken-up-into-multiple-lines that has some useful comments, but that's as far as I've got.
Created attachment 366573 [details] backtrace This time with --debug to valac and with -DCMAKE_BUILD_TYPE=Debug.
(In reply to oliver.steven from comment #11) > This time with --debug to valac and with -DCMAKE_BUILD_TYPE=Debug. Thanks, I wondered why the Vala line numbers and arguments were missing, e.g. it now shows:
+ Trace 238321
You could try doing a backtrace for all threads with the command: thread apply all bt There might be a few more tips here: https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces/Details I've not debugged GTK+ apps in this much detail, but I'm surprised there are 44000+ stack frames shown in the GTK thread. It seems to follow a pattern of calling gtk_widget_size_allocate_with_baseline () and then emitting a signal. The docs for gtk_widget_size_allocte_with_baseline () say "In this function, the allocation and baseline may be adjusted. It will be forced to a 1x1 minimum size, and the adjust_size_allocation virtual and adjust_baseline_allocation methods on the child will be used to adjust the allocation and baseline. Standard adjustments include removing the widget's margins, and applying the widget’s “halign” and “valign” properties". So you might want to check that area of your code, so see if you are adjusting properties when you don't need to.
I still can't find a correlation of the problem with vala. I assume this is somehow caused by gtk+ while your application worked on Xenial/16.04 with gtk+ 3.18.9 it fails with a newer ones. So this seems to hit the GtkTextView nested in the GtkScrolledWindow in some weird way. Even replacing the multiple settings of TextBuffer's text-property with a StringBuilder didn't work.
(In reply to oliver.steven from comment #0) > Will Seg Fault: > txtViewDragResults.buffer.text += ("Initial Velocity: %.2f ft/s Zero > Range: %.2f yards Shooting Angle: %.2f degrees\n").printf (lsln.getMv > (), lsln.getZerorange (), lsln.getAngle ()) ; > > Will print as expected: > txtViewDragResults.buffer.text += ("Initial Velocity: %.2f ft/s Zero > Range: %.2f yards\n").printf (lsln.getMv (), lsln.getZerorange ()) ; Just a thought: is the string line length too long for a single line in the text box and that triggers some weird bug in GTK+?
(In reply to Al Thomas from comment #14) > Just a thought: is the string line length too long for a single line in the > text box and that triggers some weird bug in GTK+? I tested this theory already. The box will take significantly longer lines than the one being generated.
I figured out how to fix my issue, but I still don't really understand why this was a problem in the first place. I pruned down my project to the bare necessities I needed to create the issue. This included removing whole source code files, modifying the remaining source code files, and even removing objects from my Glade UI files. After all of that was done, the program was still crashing. Finally, I started playing around in Glade to see if there was another way to display my results besides a text view. While trying to add back my text view to another object I found I could use a ViewPort instead of a ScrolledWindow. I have no idea how I stumbled upon that. Anyway, replacing the ScrolledWindow with ViewPort appears to have fixed my issue! Perhaps Rico Tzschichholz was correct, this is some of king of obscure GTK bug and not a Vala issue.