[Edbrowse-dev] What? How did this ever work?

[Edbrowse-dev] What? How did this ever work?

[Karl Dahlke]

Well this is really embarrassing.

Open your Bible's please to html.cpp, function buildTagArray().
What does this do?
When I parse the html page I build a link list of tag structures,
one for each <tag> on the page.
Then at the end, buildTagArray copies them over into one linear array
for easy access.
Now I can get my hands on tag[17] easily.
But ... have a look at the structure htmlTag.
It has this member.

struct htmlTag *controller;

This usually points to the form that owns the tag.
So an input field, or a submit or reset button,
or radio button, they all point back to the form that contains it.
Ok but that's a pointer, and it points to the form tag
that was put into my link list.
When all those tags are copied over into the array,
the pointers are not updated.
They still point back to the structures in my link list.
t->controller points to a structure that isn't even in the array.

Why would this ever work?
Probably because I made a second mistake, and never freed the structures
in the link list.
So those copies are still there.
t->controller points to the old copy of <form>, which isn't
the active copy, but is still around because I didn't free it.

I still can't imagine this would work all the time.
There must be some times when I am modifying the form tag
in the array, and input fields are modifying the form tag
in the link list, and they diverge, and results are not consistent.
I have to think it will cause trouble eventually,
in some hard to predict situations.

Anyways, it's crazy.
While I'm in here I have to rewrite all this stuff.
The member should probably be

int controller_idx;

The index of the form tag in the array that owns this input field.
A little more indirection, but it will always be right,
even if the tag array is reallocated as it grows.
And there are other static variables in html.cpp, like

currentForm currentSel currentOpt etc

that are pointers and could be invalid as their structures
move about in memory.

As I say, I can't believe it works at all.

So leave html alone for a while, and I'll
try to program some sanity back into it.

Karl Dahlke

Re: [Edbrowse-dev] What? How did this ever work?

[Chris Brannon]

> Then at the end, buildTagArray copies them over into one linear array
> for easy access.

But it doesn't copy the structs.  The array is an array of pointers to structs.
So tagArray[x]->controller *should* be one of the pointers in tagArray.

-- Chris

Re: [Edbrowse-dev] What? How did this ever work?

[Adam Thompson]

On Sun, Feb 02, 2014 at 05:49:06PM -0500, Karl Dahlke wrote:
> What does this do?
> When I parse the html page I build a link list of tag structures,
> one for each <tag> on the page.
> Then at the end, buildTagArray copies them over into one linear array
> for easy access.
> Now I can get my hands on tag[17] easily.
> But ... have a look at the structure htmlTag.
> It has this member.
> 
> struct htmlTag *controller;
> 
> This usually points to the form that owns the tag.
> So an input field, or a submit or reset button,
> or radio button, they all point back to the form that contains it.
> Ok but that's a pointer, and it points to the form tag
> that was put into my link list.
> When all those tags are copied over into the array,
> the pointers are not updated.
> They still point back to the structures in my link list.
Yeah, but this array is an array of pointers to structs.  However if things get reallocated then you'll get this divergence.
Perhaps that's why t->controller is causing the weird jsrt segfault I was reporting.
I'd always assumed it was some strange js and html interaction,
but if something in what I'm doing is causing the form tag to be reallocated before I
click the reset button then that'd explain the segfault with the 
t->controller pointer.
Anyway, I'm glad you're going to sort this.

Cheers,
Adam.