[Vala] Crashes after moving a vala application from a 32-bit system to a 64-bit system

[tomw]

Hi,
recently I was trying to move a vala application from a 32-bit system to
a 64-bit system. Like with Python and GI I thought it should be a piece
of cake. But to my surprise the vala application was crashing on the new
system. All the underlying components like clutter, etc. are working
fine as they are used by the Python apps as well.

Is there anything particular, like compiler options or the like I should
be aware of ?

Thanks,

--
tomw <to...@ubilix.com>

_______________________________________________
vala-list mailing list
vala...@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Fabian Deutsch]

Am Donnerstag, den 15.03.2012, 08:29 +0100 schrieb tomw:
> Hi,
> recently I was trying to move a vala application from a 32-bit system to
> a 64-bit system. Like with Python and GI I thought it should be a piece
> of cake. But to my surprise the vala application was crashing on the new
> system. All the underlying components like clutter, etc. are working
> fine as they are used by the Python apps as well.
>
> Is there anything particular, like compiler options or the like I should
> be aware of ?

It would help if you provided some more informations on the crash, e.g.
a stacktrace or other errors.

- fabian

[tomw]

> It would help if you provided some more informations on the crash, e.g.
> a stacktrace or other errors.
>

sure, you're right - here we go:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7551ed2 in clutter_gst_player_set_property (object=0x7fffe80042f0, property_id=34, value=0x7fffffffe270, pspec=0x1836800) at ./clutter-gst-player.c:1410
1410 ./clutter-gst-player.c: No such file or directory.
in ./clutter-gst-player.c
(gdb) bt
#0 0x00007ffff7551ed2 in clutter_gst_player_set_property (object=0x7fffe80042f0, property_id=34, value=0x7fffffffe270, pspec=0x1836800) at ./clutter-gst-player.c:1410
#1 0x00007ffff2c1fe72 in g_object_set_property () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#2 0x00007ffff7553472 in clutter_gst_parse_caps (caps=<optimized out>, sink=0x19a1640, save=1) at ./clutter-gst-video-sink.c:441
#3 0x00007ffff75535fe in clutter_gst_source_dispatch (source=0x1b557f0, callback=<optimized out>, user_data=<optimized out>) at ./clutter-gst-video-sink.c:484
#4 0x00007ffff254a0cf in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007ffff254a8c8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6 0x00007ffff254ae02 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#7 0x00007ffff612b6cd in clutter_main () at ./clutter-main.c:675

on top of that valac spits quite some warnings like:

**(valac:8560): CRITICAL **: vala_code_node_get_attribute_string: assertion `self != NULL'failed

which I haven't seen before with the same code. Hope that sheds some light on the issue...