After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 618933 - Segmentation fault and error when referencing a constant structure or symbol
Segmentation fault and error when referencing a constant structure or symbol
Status: RESOLVED OBSOLETE
Product: vala
Classification: Core
Component: Code Generator
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2010-05-17 21:10 UTC by pancake
Modified: 2018-05-22 13:35 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gdb session of segfault (2.88 KB, text/plain)
2010-05-17 21:10 UTC, pancake
  Details
patch for vala constant reference and global symbols (904 bytes, patch)
2010-05-17 21:12 UTC, pancake
none Details | Review

Description pancake 2010-05-17 21:10:38 UTC
Created attachment 161277 [details]
gdb session of segfault

The following code makes valac segfault:


/* valac --pkg r_lib plugin.vala --library=plugin */
using Radare;

[CCode (has_target = false)]
bool mycall(void *user, string cmd) {
        print ("Hello World from Vala!\n");
        return true;
}

const RCmdHandle plugin = {
        "my plugin", mycall
};

const RCmdStruct radare_plugin = {
        RLibType.CMD, ref main // plugin
};
----

By defining it locally, it compiles and runs fine.

void main() {
        RCmdHandle local_plugin = {
                "my plugin", mycall
        };
        RCmdStruct local_radare_plugin = {
                RLibType.CMD, ref local_plugin
        };
}

------
I attach the gdb session with the segmentation fault and the patch that fixes the compiler to support this kind of references.

Maybe we should handle other conditions, so this patch needs review.
Comment 1 pancake 2010-05-17 21:12:50 UTC
Created attachment 161278 [details] [review]
patch for vala constant reference and global symbols

This patch makes the following constructions compile:

const RCmdStruct radare_plugin = {
        RLibType.CMD, ref main
};

and 

const RCmdStruct radare_plugin = {
        RLibType.CMD, ref plugin
};
Comment 2 Jürg Billeter 2010-06-05 09:16:55 UTC
The compiler should not crash, of course, however, I don't think it makes sense to support ref/out for constants and methods. ref/out usually modify the value which is not allowed for constants or methods. Can you please post a complete test case?
Comment 3 pancake 2010-06-06 00:17:28 UTC
As discussed in IRC, this example can be done by using just pointer arithmetic with structs, so the patch is not required, but the segfault is still there. Here's some backtrace info:

(gdb) r
Starting program: /usr/bin/valac -g -o rbc.so --library=rbc --Xcc=-fPIC --Xcc=-shared --vapidir=../swig/vapi --vapidir=. --pkg xmlrpc --Xcc=-Wl,-lxmlrpc --Xcc=-Wl,-lxmlrpc_client --pkg r_core --pkg r_anal --pkg r_util --pkg r_asm --pkg r_lib --pkg r_cmd --pkg r_config node.vala edge.vala function.vala target.vala radaretarget.vala bincrowd.vala primes.vala argument.vala plugin.vala
[Thread debugging using libthread_db enabled]
plugin.vala:111.50-111.59: error: ref and out method arguments can only be used with fields, parameters, local variables, and array element access
const RCmdStruct radare_plugin = { RLibType.CMD, ref plugin };
                                                 ^^^^^^^^^^

Program received signal SIGSEGV, Segmentation fault.
0xb7e97d3c in vala_data_type_compatible (self=0x0, target_type=0x88ea778) at valadatatype.c:1133
1133            return VALA_DATA_TYPE_GET_CLASS (self)->compatible (self, target_type);
(gdb) bt
  • #0 vala_data_type_compatible
    at valadatatype.c line 1133
  • #1 vala_constant_real_check
    at valaconstant.c line 1623
  • #2 vala_code_node_check
    at valacodenode.c line 361
  • #3 vala_source_file_check
    at valasourcefile.c line 701
  • #4 vala_semantic_analyzer_real_visit_source_file
    at valasemanticanalyzer.c line 1829
  • #5 vala_code_visitor_visit_source_file
    at valacodevisitor.c line 1317
  • #6 vala_source_file_accept
    at valasourcefile.c line 347
  • #7 vala_code_context_accept
    at valacodecontext.c line 495
  • #8 vala_semantic_analyzer_analyze
    at valasemanticanalyzer.c line 1817
  • #9 vala_compiler_run
    at valacompiler.c line 761
  • #10 vala_compiler_main
    at valacompiler.c line 1187
  • #11 main
    at valacompiler.c line 1195
  • #1 vala_constant_real_check
    at valaconstant.c line 1623
$1 = (ValaConstant *) 0x8857848
(gdb) print vala_constant_get_initializer (self)
$2 = (ValaExpression *) 0x8865280
(gdb) print vala_expression_get_value_type (vala_constant_get_initializer (self))
$3 = (ValaDataType *) 0x0
(gdb)
Comment 4 Tobias Mueller 2010-11-06 13:07:42 UTC
Hm. Reopening as I think the requested information has been provided.
Comment 5 Fabio Durán Verdugo 2011-08-09 18:58:06 UTC
maybe this is related with bug 651151
Comment 6 GNOME Infrastructure Team 2018-05-22 13:35:54 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vala/issues/99.