On Thu, 11 Nov 2010 23:45:39 +0100
Pelle Månsson <[email protected]> wrote:
> 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.
Sorry, but I don't understand your hint. Where is the dup-ed array supposed to
be allocated? Isn't the assignment supposed to copy it to the field, anyway?
How else could one store an array to a field? And how are contained referenced
objects supposed to stop vanishing thank to dup?
(I tried, anyway, but the did not stop segfault.)
I have one more example of segfault, in a brand new demo func matching 4
operations. Very strange. With additions, all works fine. When I replace '+' by
'-', I get a segfault _sometimes_. When I use '*' or '/', seems I get a
segfault _everytime_. The patterns for the 4 operations are all the same,
indeed.
Also, since the demo matches calculations of several operations, there can be
whitespace. If I add some space after the operation, I get a segfault even for
'+'.
What I intend to do is uninstall dmd2 to replace it by dmd1 and see what
happens. What do you think?
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
