SCM

[#1368] Event sequence objects sometimes cause segmentation faults

Date:
2011-04-24 16:32
Priority:
3
State:
Open
Submitted by:
Pierre Moulinier (pmoulinier)
Assigned to:
Nobody (None)
Resolution:
None
Severity:
major
TraMineR version:
None
E-Mail address:
pierre.moulinier@free.fr
Summary:
Event sequence objects sometimes cause segmentation faults

Detailed description
Traminer version 1.6-2

In various cases, the event sequence objects obtained via a call to "seqecreate" are not valid. They cause infinite loops when passed to anciliary functions such as seqefsub, or randomly cause segfaults when the user tries to display them.

One way to reproduce this is to create an event sequence object, exit R saving the workspace, go back into R and attempt to display the sequence object (after reloading TraMineR). This should cause a segfault.

Unfortunately this sometimes also happens without exiting R. The attached .RData file contains an object called tsedata. Executing :
> x = seqecreate(tsedata)
> x

will cause a segfault.

Surprisingly enough, executing :
> x = seqecreate(tsedata[702,])
> x

does not cause the segfault. However, the resulting "x" object is still invalid : it causes the seqefsub function to block indefinitely.

I am not sure there is a single cause involved here, and maybe these different issues ought to be filed in separate bugs. However it definitely seems that there is something wrong with the way event sequence objects are built.

Best regards,
Pierre

Comments:

Message  ↓
Date: 2011-05-04 10:09
Sender: Matthias Studer

Dear Pierre,

Many thanks for your bug report and for the example dataset that allowed me to quickly find the reported bugs. As you say, your bug report relates to different issues.

Actually, event sequences object may not be saved. Internally, event sequences objects are handled as a C structure and R provides no interface to save custom C structure. I think that workaround would be possible but may require more computation at each step. Anyway, it should be possible to provide an error message instead of segfault.

Regarding the second issue, the bug is located in the as.character function of the sequence object and is due to the fact that each of your sequences contains a lot of events. This is now fixed in the development version (see "R Packages" above and/or our main website for instructions on how to install).

Regarding the fact that seqefsub seems to block indefinitely, this is due to the number of events in each of your event sequences (around 200). The number of possible subsequences explodes with the length of each sequence. By default seqefsub try to find all possible subsequences, which, in your case, is impossible (too many possibilities). One workaround is to constrain the search of subsequences using "seqeconstraint" and/or using the maxK argument of seqefsub. maxK allow to specify the maximum number of events allowed in a subsequence, which reduces considerably to number of subsequence to search for. You may try to run seqefsub with a maxK of 4 (maybe 5 but not much higher).

Thanks again.
Best regards,
Matthias

Attached Files:

Attachments:
Size Name Date By Download
5 KiB.RData2011-04-24 16:32pmoulinier.RData

Changes

Field Old Value Date By
File Added95: .RData2011-04-24 16:32pmoulinier
Thanks to:
Vienna University of Economics and Business Powered By FusionForge