spir denis.spir at
Fri Nov 12 03:34:02 PST 2010

On Thu, 11 Nov 2010 23:45:39 +0100
Pelle Månsson <pelle.mansson at> 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?

-- -- -- -- -- -- --
vit esse estrany ☣

More information about the Digitalmars-d-learn mailing list