[datatable-help] Random segfaults

[Chris Neff]

So far so good. The state before this latest patch was I would run my
script, and then try to mess with the resultant data.table, and almost
immediately it would segfault. 10 minutes of playing and no segfaults
yet.  Will update if there is one.

On 19 December 2011 20:12, Chris Neff <caneff at gmail.com> wrote:
> I definitely do that somewhere in my code. I'll patch tomorrow and try.
>
> On 19 December 2011 19:03, Matthew Dowle <mdowle at mdowle.plus.com> wrote:
>> Chris,
>>
>> Are you returning any character or list() columns in j when grouping? If
>> so, Jim Holtman provided a reproducible example and a fix has just been
>> committed. Same errors / seg faults, and, for R >= 2.14.0, not just R <
>> 2.14.0. Could this also be the same problem Timothée Carayol mentioned?
>> Fingers crossed ...
>>
>> Matthew
>>
>>
>> On Sat, 2011-12-17 at 00:27 +0000, Matthew Dowle wrote:
>>> It'd be good to get to the bottom of it in case it's not a pre-2.14.0
>>> problem.  Try this :
>>>
>>> apt-get install valgrind  (if not already installed)
>>> R -d valgrind
>>> require(data.table)
>>> test.data.table()
>>>
>>> When I do this it runs very slowly but eventually completes ok with just
>>> test 120 failing. Test 120 is a timing test, which takes longer because
>>> of valgrind mode, so that's ok. Ignore the valgrind messages for R
>>> itself that happen before R's banner comes up.
>>>
>>> If you get the same, then proceed to run your tests that crash it.
>>> Hopefully you'll get some messages at the point the corruption occurs.
>>>
>>>
>>> On Fri, 2011-12-16 at 12:37 -0500, Chris Neff wrote:
>>> > >
>>> > > Only other thought ... your special internal build of R ... does it
>>> > > increase R_len_t on 64bit to allow longer vectors than 2^31, by any
>>> > > chance?  I've used R_len_t quite a bit in data.table to future proof for
>>> > > when that happens, but if you've done it already in your build then that
>>> > > would help to know since it's never been tested afaik when R_len_t != int
>>> > > on 64bit.  I'm also assuming R_len_t is signed. If your R has R_len_t as
>>> > > unsigned would need to know.
>>> >
>>> > Answer to this is no, we haven't touched that.
>>> >
>>> > I'm happy to keep helping, but if you'd rather not worry about that
>>> > stuff, we will be upgrading to 2.14 in the next few months apparently,
>>> > and I can live with 1.7.1 until then.
>>>
>>>
>>> _______________________________________________
>>> datatable-help mailing list
>>> datatable-help at lists.r-forge.r-project.org
>>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help
>>
>>