Documentation bugs

[Thomas Kuehne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jari-Matti Mäkelä schrieb am 2006-03-10:
> Jari-Matti Mäkelä wrote:
>> Thomas Kuehne wrote:
>>> Jari-Matti Mýkelý schrieb am 2006-03-08:
>>>
>>> [snip]
>>>
>>>>> 4. One other question - what are the hard limits of DMD? For example,
>>>>> how many objects of a class can be instantiated at most? We have made a
>>>>> suffix tree -algorithm that generates a huge amount of objects. I think
>>>>> the compiler introduces some limits, since the algorithm segfaults only
>>>>> after about >300 identical successful runs - the amount of successful
>>>>> identical runs before segfault decreases when the tree depth increases.
>>>>> It segfaults on the following code:
>>>>>
>>>>> class Node {
>>>>>   Node[char] children;
>>>>>   char[] label;
>>>>>
>>>>>   void fn(char[] s) {
>>>>>     assert(s !is null);
>>>>>     assert(s.length > 0);
>>>>>     assert(s[0] in children);
>>>>>     auto a = children[s[0]];
>>>>>     assert(a !is null);
>>>>>     char[] l = a.label;  // segfault exactly here
>>>>>     assert(l != null);
>>>>>     ...
>>>>>   }
>>>>> }
>>>>>
>>>>> The segfault shouldn't be possible since all objects all guaranteed to
>>>>> be properly allocated from the heap. We don't use any explicit memory
>>>>> management. I can post the whole source if needs be.
>>> Are you sure you aren't hitting the memory limit of your system?
>> 
>> No, I think I'm not. The program is consuming < 50 MB of memory and I
>> have > 2 GB of physical RAM + swap. It takes a while to fill all memory
>> (especially the swap partition), but this algorithm segfaults already in
>> 1-2 seconds. I have another D program that is trying to fill up the
>> memory as fast as possible with small linked lists. It's only able to
>> occupy ~300 MB in 2 seconds.
>> 
>> I'm not sure, but I think the problem is in the slicing code (most
>> probably), in associative arrays or in the code that creates new
>> instances of classes. I'm working on a minimal test case. It's ~200 LOC now.
>> 
> Well, one thing I found out is that the algorithm segfaults exactly when
> the input strings for the suffix tree are long enough (>180 chars) or
> the algorithm is repeated several hundreds of times. It works perfectly
> with shorter input strings. If I try to writefln the segfaulting node
> contents, the runtime reports that the node labels are invalid unicode -
> this is very strange since the input strings consist of characters a-f,
> which are represented using 8-bit values and should remain valid
> throughout the slicing processes.
>
> Ok, then I tried to change the data type from char[] to dchar[] and now
> I'm not encountering any problems anymore. Maybe there are some problems
> with the implementation of slices on the char-type? One other thing I
> noticed was that this segfaulted sometimes too:
>
> char[] teststring = "testing";
> doAlgorithm(teststring);
> writefln("%s", teststring); // segfault here.
>
> the algorithm doesn't write to the string, change its length nor does it
> free/delete it in any way. Just plain slicing and reference passing.
> Very weird.

Please replace
> doAlgorithm(teststring);
with 
> doAlgorithm(teststring.dup);

I know the behaviour shouldn't change as "the algorithm doesn't write to
the string", but ...

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFEETQL3w+/yD4P9tIRAtUIAKDTHmAHkQhPfBujP3rXeVsqzu/CjQCgqaOZ
mVWeOozmJt+bYTDJxrWZH2E=
=xbc+
-----END PGP SIGNATURE-----