mouse07410 / asn1c

The ASN.1 Compiler
http://lionet.info/asn1c/
BSD 2-Clause "Simplified" License
93 stars 70 forks source link

Help debugging "Segmentation fault (core dumped)" #152

Open mennowo opened 8 months ago

mennowo commented 8 months ago

Hello,

I'm using asn1c to decode ASN.1 UPER encoded data from vehicles (see here). I built asn1c from source in Cygwin, and it seems to work, however, when I give this command, I get "Segmentation fault (core dumped)".

./asn1c.exe -fincludes-quoted -fincludes-quoted -no-gen-print -no-gen-example -no-gen-BER -no-gen-XER -no-gen-JER -no-gen-OER -no-gen-APER -S /home/menno/asn1c-vlm_master/skeletons/ -D /home/menno/O1/ /home/menno/asn/ITS-Container.asn /home/menno/asn/DSRC_REGION_noCircular.asn /home/menno/asn/DSRC.asn /home/menno/asn/AddGrpC_noCircular.asn /home/menno/asn/AddGrpC.asn /home/menno/asn/REGION.asn /home/menno/asn/SREM-PDU-Descriptions.asn

Any ideas as to how I could debug this issue? These are the asn files: asn.zip. I'm afraid that in the absence of an IDE, I am a bit at a loss as to how to go about and find out what is causing the issue.

Any help is appreciated!

mennowo commented 8 months ago

Follow up:

mouse07410 commented 8 months ago

Way too little information to even approach this problem.

What OS? What compiler? How was the asn1c built - with optimization, or not (if with optimization - turn it off, and instead enable full debugging, like adding flags -g2 -ggdb and removing -O)?

More importantly - report from the core dump? Where exactly does it crash in the code? Perhaps, run asn1c under debugger to glean more useful information?

Having asked all that - there's a good chance that I won't be able to find (and therefore fix) the problem. Just to set the expectations... :-(

mennowo commented 8 months ago

Thank you for your response. I will try as you suggest and run asn1c under the debugger. First I'll have to find out how to do that in Cygwin, but it should be doable.

I built asn1c under Windows11 64bits in Cygwin with simply running configure and make as it says in the readme. So I guess that means the gnu c compiler. If it would be way easier to do the debugging under Ubuntu, that would also be an option. I normally use Visual Studio for building/debugging, so doing this in the console is new for me.

As for expectations, I have none, it's always worth a try to find the cause, and who knows it is something that could be fixed. And if not I will make do (-:

v0-e commented 8 months ago

It appears to be related with a missing definition to Control-addGrpC in your AddGrpC_noCircular.asn. It appears to be defined in AddGrpC.asn commented in C-style. You can try moving it to AddGrpC_noCircular.asn for example. These ASNs files seem to be a little be hacky (_noCircular.asn, etc.), maybe you were trying to resolve another underlying issue?

The compiler shouldn't crash however. It seems to be related with the unexpected lack of that definition. This commit seems to resolve the issue.

mennowo commented 8 months ago

Thank you @v0-e ; your comment made me look more closely at the ASN.1 specs. I found there was another version of these files here. With these versions, things work fine if I use the -fcompound-names flag. I only get a warning: WARNING: Parameterized type REG-EXT-ID-AND-TYPE expected for REG-EXT-ID-AND-TYPE at line 65 in /home/menno/V1/DSRC.asn, but things work fine anyway.

Sorry for the confusion, I am unsure why there are multiple versions of these specs in the ETSI repo.

After applying some patches to the resulting code (with some help from this repo: placeholders in empty unions, fixing circular dependencies, and then also adding a non-existing jer_decoder field to asn_TYPE_operation_s so aren't too many initializer values), UPER decoding now works fine.

Before, I actually used the generated code from the vanetza repo, which works, but it uses a newer version of the given ASN.1 specs, and I would always get RC_WMORE, which worried me slightly. Now I get RC_OK, hurray!

In case you still want to solve the segfault, I am happy to debug this, and check if the mentioned commit fixes the problem. Otherwise, we can close this issue.

mouse07410 commented 8 months ago

After applying some patches to the resulting code (with some help from this repo: placeholders in empty unions, fixing circular dependencies, and then also adding a non-existing jer_decoder field to asn_TYPE_operation_s so aren't too many initializer values), UPER decoding now works fine.

@mennowo do I understand correctly that those patches are applied after asn1c completed generating code? To that resulting code? I wonder if that's a problem with UPER decoder that we could fix, based on these patches?

Also, I applied the recommended patch for segfault (thanks, @v0-e ) - could you please pull the current vlm_master and confirm that it works (aka, does not segfault)?

mennowo commented 8 months ago

Thank you @mouse07410, I will compile and test the new version end of this week or beginning of the next and see if the segfault is gone. Given the messy ASN.1 specs I was using, I would then expect some error message. I will report back about this.

About the patches: yes, in order to be able to compile the code (on Windows 11, both x64 and x86, in Visual Studio 2022), I need to do the following:

First, given this code from the ASN.1 spec:

Reg-SignalRequestMessage            REG-EXT-ID-AND-TYPE ::= { ... }   

generates an empty union, which I need to add a placeholder to:

/* RegionalExtension */
typedef struct Reg_SPAT {
    RegionId_t   regionId;
    struct Reg_SPAT__regExtValue {
        Reg_SPAT__regExtValue_PR present;
        union Reg_SPAT__regExtValue_u {
            char _placeholder; /* avoid empty union */ /* << this is added manually */
        } choice;   

        /* Context for parsing across buffer boundaries */
        asn_struct_ctx_t _asn_ctx;
    } regExtValue;
    /* Context for parsing across buffer boundaries */
    asn_struct_ctx_t _asn_ctx;
} Reg_SPAT_t;

An empty union will give compiler errors, at least under Windows + VS. Maybe asn1c can add such a placeholder automatically?

Then in order to avoid circular references, a couple of include statements need to be moved from generated headers to generated sources. This patch file lists the details, they are using ASN.1 specs very similar to the ones I am using. I don't know if this would make apparent what would need to be changed about asn1c? Without the patching, the code will not compile.

Finally, this generated code gave me a compiler error stating "too many initializer values", for example in the file BOOLEAN.c, and some other places; I now see that I was including a skeletons folder from a version of asn1c from some weeks ago, which had no JER decoder field. This was since added, so that was actually my own mistake, now fixed.