segfault
Pelle Månsson
pelle.mansson at gmail.com
Thu Nov 11 14:45:39 PST 2010
On 11/11/2010 10:15 PM, spir wrote:
> Well, since the pattern is OK _after_ call to Tuple's constructor (which does nothing more than recording its sub-patterns, see below) and only gets wrong when qutting this(), I fail to see how Tuple could be cause of anything. Also, the corruption is visible _before_ calling match() (which here delegates to Tuple's check()).
>
> I understand your note about returning an object actually allocated on the stack -- but here there are only implicitely referenced objects (class instances). This would mean that D creates the 2 sub-patterns on the stack? But why those objects, precisely? (Also note that they are of different classes: one is here a "String", the other a "ZeroOrMore"). They are stored in an array.
>
> What's troubling is that the array elements, meaning the supposed subpattern addresses, have changed. Maybe the patterns themselves are still ok, but the array data only are corrupted?
> Oh, I may try to cast to String the memory area pointed inside this()....... Does not seem to work: I recorded the pointer read in this() (as String*) into a global; then in the test func:
> writeln("p: ",p); // ok, same address as in this()
> writeln(cast(String)(*p)); // segfault!
>
> Anyway, just in case my reasoning is wrong, here is the whole Tuple class:
>
> ====================================================
> class Tuple : Pattern {
> /** pattern type for tuple of given patterns */
> static string typename = "Tuple";
> Pattern[] patterns;
> this (Pattern[] patterns...) {
> this.patterns = patterns;
You need to dup that. Arguments are passed on the stack.
More information about the Digitalmars-d-learn
mailing list