473,320 Members | 2,107 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Spot the Bug: Fun Concurrency Bug

I hit this bug last night in some test code I had written. It took a few
minutes to figure out what the root cause was, and it left me thinking,
"Wow. That was an interesting one that doesn't come up very often!".

So, for fun, who sees the bug and can explain why it's happening?

List<Threadthreads = new List<Thread>();
for (int i = 0; i < 2; i++)
{
Thread t = new Thread(delegate()
{
Debug.Assert(i != 2);
});

t.Start();
threads.Add(t);
}

foreach (Thread thread in threads)
thread.Join();

--
Chris Mullins
Oct 24 '07 #1
19 1461
Chris Mullins [MVP - C#] wrote:
I hit this bug last night in some test code I had written. It took a few
minutes to figure out what the root cause was, and it left me thinking,
"Wow. That was an interesting one that doesn't come up very often!".

So, for fun, who sees the bug and can explain why it's happening?
Define "bug".

Assuming your main thread doesn't get preempted while creating the
threads, both threads are going to fail the assertion. And since the
main thread is doing so little, it is in fact likely to get all the way
to the first call to Join() before another thread gets to run.

But is that a bug? The Debug class is thread-safe, so having two
threads concurrent fail an assertion shouldn't cause a problem in and of
itself.

Pete
Oct 24 '07 #2
Even though it does deal with concurrency, I wouldn't file this under a
concurrency issue, per se. The error comes from using an anonymous method
in the loop and capturing the variable "i".

Because it is used in the anonymous method (and there is only one
instance of it created), when the loop exits, i is equal to 2. Not all the
threads have started up by this point, and then by the time that they do,
the assertion fails.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Chris Mullins [MVP - C#]" <cm******@yahoo.comwrote in message
news:e6**************@TK2MSFTNGP02.phx.gbl...
>I hit this bug last night in some test code I had written. It took a few
minutes to figure out what the root cause was, and it left me thinking,
"Wow. That was an interesting one that doesn't come up very often!".

So, for fun, who sees the bug and can explain why it's happening?

List<Threadthreads = new List<Thread>();
for (int i = 0; i < 2; i++)
{
Thread t = new Thread(delegate()
{
Debug.Assert(i != 2);
});

t.Start();
threads.Add(t);
}

foreach (Thread thread in threads)
thread.Join();

--
Chris Mullins

Oct 24 '07 #3
On Oct 24, 2:19 pm, "Chris Mullins [MVP - C#]" <cmull...@yahoo.com>
wrote:
I hit this bug last night in some test code I had written. It took a few
minutes to figure out what the root cause was, and it left me thinking,
"Wow. That was an interesting one that doesn't come up very often!".

So, for fun, who sees the bug and can explain why it's happening?

List<Threadthreads = new List<Thread>();
for (int i = 0; i < 2; i++)
{
Thread t = new Thread(delegate()
{
Debug.Assert(i != 2);
});

t.Start();
threads.Add(t);

}

foreach (Thread thread in threads)
thread.Join();

--
Chris Mullins
Hi Chris,
It looks like you're incrementing i to 2 before the threads start.
You can see the same thing with one thread and no anonymous delegate:

private static int _global;
public static void Main()
{
_global = 1;
Thread t = new Thread(MyThreadProc);
t.Start();

_global = 2;
t.Join();
}

public static void MyThreadProc()
{
Debug.Assert(_global != 2);
}

Oct 24 '07 #4
It's not a .Net bug or anything like that, but it's certainly a bug in the
sense that "my code doesn't do what I wrote it to do" sense.

The convergence of technology that caused this to happen made for a weird
debugging process. When you run it in the debugger, it works just fine (as
do most race conditions). Inspecting all the variables always shows the
correct results, etc.

I've seen many people do thing like this with Closures, and the fact that
the passed variable changes makes the code very strange to follow...

It was also confusing, as I *expected* the variable passed into the closure
to be passed by value (it's an int, afterall). I expected to get the same
behavior as if I had passed in a constant. The fact that C# boxed the
variable, passed in a reference to it, and then later checked it after the
for-loop had completed (and the original variable was out of scope) and got
the "illegal" variable, really was amusing...

--
Chris

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.comwrote in
message news:et**************@TK2MSFTNGP04.phx.gbl...
Even though it does deal with concurrency, I wouldn't file this under a
concurrency issue, per se. The error comes from using an anonymous method
in the loop and capturing the variable "i".

Because it is used in the anonymous method (and there is only one
instance of it created), when the loop exits, i is equal to 2. Not all
the threads have started up by this point, and then by the time that they
do, the assertion fails.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Chris Mullins [MVP - C#]" <cm******@yahoo.comwrote in message
news:e6**************@TK2MSFTNGP02.phx.gbl...
>>I hit this bug last night in some test code I had written. It took a few
minutes to figure out what the root cause was, and it left me thinking,
"Wow. That was an interesting one that doesn't come up very often!".

So, for fun, who sees the bug and can explain why it's happening?

List<Threadthreads = new List<Thread>();
for (int i = 0; i < 2; i++)
{
Thread t = new Thread(delegate()
{
Debug.Assert(i != 2);
});

t.Start();
threads.Add(t);
}

foreach (Thread thread in threads)
thread.Join();

--
Chris Mullins


Oct 24 '07 #5
Well, it's a bug in that the code doesn't do what was originally intended.
Instead an "impossible" assertion fires, and the developer(s) get a very
confused look on their faces for a few minutes...

Your explination is dead on, but the boxing / byref behavior of the variable
passed into the Closure is what made this code behavie in a way other than
was expected. I was expecting the int (a value type) to be passed in by
value, and therefore not change...

--
Chris Mullins

"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:13*************@corp.supernews.com...
Chris Mullins [MVP - C#] wrote:
>I hit this bug last night in some test code I had written. It took a few
minutes to figure out what the root cause was, and it left me thinking,
"Wow. That was an interesting one that doesn't come up very often!".

So, for fun, who sees the bug and can explain why it's happening?

Define "bug".

Assuming your main thread doesn't get preempted while creating the
threads, both threads are going to fail the assertion. And since the main
thread is doing so little, it is in fact likely to get all the way to the
first call to Join() before another thread gets to run.

But is that a bug? The Debug class is thread-safe, so having two threads
concurrent fail an assertion shouldn't cause a problem in and of itself.

Pete

Oct 24 '07 #6
Chris Mullins [MVP - C#] wrote:
[...]
It was also confusing, as I *expected* the variable passed into the closure
to be passed by value (it's an int, afterall). I expected to get the same
behavior as if I had passed in a constant. The fact that C# boxed the
variable, passed in a reference to it, and then later checked it after the
for-loop had completed (and the original variable was out of scope) and got
the "illegal" variable, really was amusing...
Maybe someone who has more intimate knowledge can comment, but AFAIK
this isn't a case of the value type being boxed. If it were, you
wouldn't have had the problem, since the boxing still preserves the
value as it was at the moment of boxing, not referencing the variable
itself.

Rather, by capturing the variable in the anonymous method, what is being
used in the method is the variable itself. That's why any change to the
variable that happens before the code that uses it is executed is seen
when that code is executed.

The key here is the "capturing" behavior, and I believe that has nothing
to do with boxing.

I think the variable capturing that happens with anonymous methods is
pretty cool, actually. But I agree it can lead to some non-obvious
results when one is not aware that the capturing is going on, and what
the capturing does.

Pete
Oct 24 '07 #7
Chris Mullins [MVP - C#] wrote:
Well, it's a bug in that the code doesn't do what was originally intended.
Instead an "impossible" assertion fires, and the developer(s) get a very
confused look on their faces for a few minutes...
I'm glad you put "impossible" in quotes. :)
Your explination is dead on, but the boxing / byref behavior of the variable
passed into the Closure is what made this code behavie in a way other than
was expected. I was expecting the int (a value type) to be passed in by
value, and therefore not change...
I think my other post elaborates on this already, but I think it's
important to note that not only is there no boxing, I don't think it's
actually that the variable is being "passed" either. So it's not really
correct to talk about the variable be passed by reference or by value.
It's captured, not passed.

If you did want the value passed by value, you could have achieved that
by using the ParameterizedThreadStart constructor for the Thread
instances, and a delegate that actually does have a parameter. Then you
could literally pass the loop variable in by value and have things work
as you expected.

None of this is meant to downplay the potential for confusion here. I
agree that it can be confusing, if you're not familiar with the variable
capturing behavior. I have the benefit of having already been surprised
by this months ago and having Jon Skeet explain it here in this
newsgroup. :)

Pete
Oct 24 '07 #8
Peter and Chris,

There is no boxing here. What is going on here is that the compiler is
generating a class which has a public field "i" which also contains the
method which is passed to the thread for the delegate.

The field is of the same type as the variable, in this case, an int,
which means no boxing occurs.

The reason that it asserts is mentioned in my first post. Because the
scope of i actually contains the loop, there is one instance of the
anonymous class created for the delegate, for all iterations of the loop.

To have a separate instance created every time, you can replace the code
with the following:

List<Threadthreads = new List<Thread>();
for (int i = 0; i < 2; i++)
{
// Reassign i to prevent a shared anonymous method implementation.
int x = i;

Thread t = new Thread(delegate()
{
Debug.Assert(x != 2);
});

t.Start();
threads.Add(t);
}

In the code above, a new instance of the anonymous class will be created
on each iteration through the loop and then assigned to the delegate.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:13*************@corp.supernews.com...
Chris Mullins [MVP - C#] wrote:
>[...]
It was also confusing, as I *expected* the variable passed into the
closure to be passed by value (it's an int, afterall). I expected to get
the same behavior as if I had passed in a constant. The fact that C#
boxed the variable, passed in a reference to it, and then later checked
it after the for-loop had completed (and the original variable was out of
scope) and got the "illegal" variable, really was amusing...

Maybe someone who has more intimate knowledge can comment, but AFAIK this
isn't a case of the value type being boxed. If it were, you wouldn't have
had the problem, since the boxing still preserves the value as it was at
the moment of boxing, not referencing the variable itself.

Rather, by capturing the variable in the anonymous method, what is being
used in the method is the variable itself. That's why any change to the
variable that happens before the code that uses it is executed is seen
when that code is executed.

The key here is the "capturing" behavior, and I believe that has nothing
to do with boxing.

I think the variable capturing that happens with anonymous methods is
pretty cool, actually. But I agree it can lead to some non-obvious
results when one is not aware that the capturing is going on, and what the
capturing does.

Pete

Oct 24 '07 #9
Chris Mullins [MVP - C#] <cm******@yahoo.comwrote:
I hit this bug last night in some test code I had written. It took a few
minutes to figure out what the root cause was, and it left me thinking,
"Wow. That was an interesting one that doesn't come up very often!".

So, for fun, who sees the bug and can explain why it's happening?

List<Threadthreads = new List<Thread>();
for (int i = 0; i < 2; i++)
{
Thread t = new Thread(delegate()
{
Debug.Assert(i != 2);
});

t.Start();
threads.Add(t);
}

foreach (Thread thread in threads)
thread.Join();
Posting without reading any responses... "i" is captured and only has a
single "instance", so the assertion will fail if the thread executes
after the loop has "finished".

The solution:

List<Threadthreads = new List<Thread>();
for (int i = 0; i < 2; i++)
{
int j=i; // THIS IS THE CHANGE
Thread t = new Thread(delegate()
{
Debug.Assert(j != 2); // AND THIS
});

t.Start();
threads.Add(t);
}

foreach (Thread thread in threads)
thread.Join();

There's a new instance of "j" each time we go round the loop.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Oct 24 '07 #10
Jon,

I do not understand much of threading & was curious
So, I ran this using snippet compiler & couldn't see any difference in
output

<code>
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Threading;

class Sample
{
public static void Main(string[] args)
{
List<Threadthreads = new List<Thread>();
for (int i = 0; i < 2; i++)
{
int j = i;
Thread t = new Thread(delegate()
{
Console.WriteLine("inside thread: " + j);
Debug.Assert(j != 2);
});

Console.WriteLine("starting thread: " + i);
t.Start();
threads.Add(t);

}

foreach (Thread thread in threads)
thread.Join();
}
}
</code>

Could you explain, what is the problem with having to introduce j as a
temp. variable?
What is the problem with the original code (without introduction of
temp. variable inside the loop)?

Thanks
Kalpesh
On Oct 24, 12:28 pm, Jon Skeet [C# MVP] <sk...@pobox.comwrote:
Chris Mullins [MVP - C#] <cmull...@yahoo.comwrote:
I hit this bug last night in some test code I had written. It took a few
minutes to figure out what the root cause was, and it left me thinking,
"Wow. That was an interesting one that doesn't come up very often!".
So, for fun, who sees the bug and can explain why it's happening?
List<Threadthreads = new List<Thread>();
for (int i = 0; i < 2; i++)
{
Thread t = new Thread(delegate()
{
Debug.Assert(i != 2);
});
t.Start();
threads.Add(t);
}
foreach (Thread thread in threads)
thread.Join();

Posting without reading any responses... "i" is captured and only has a
single "instance", so the assertion will fail if the thread executes
after the loop has "finished".

The solution:

List<Threadthreads = new List<Thread>();
for (int i = 0; i < 2; i++)
{
int j=i; // THIS IS THE CHANGE
Thread t = new Thread(delegate()
{
Debug.Assert(j != 2); // AND THIS
});

t.Start();
threads.Add(t);

}

foreach (Thread thread in threads)
thread.Join();

There's a new instance of "j" each time we go round the loop.

--
Jon Skeet - <sk...@pobox.com>http://www.pobox.com/~skeet Blog:http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Oct 24 '07 #11
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP*********************@msnews.microsoft.com. ..
Chris Mullins [MVP - C#] <cm******@yahoo.comwrote:
>I hit this bug last night in some test code I had written. It took a few
minutes to figure out what the root cause was, and it left me thinking,
"Wow. That was an interesting one that doesn't come up very often!".

So, for fun, who sees the bug and can explain why it's happening?

List<Threadthreads = new List<Thread>();
for (int i = 0; i < 2; i++)
{
Thread t = new Thread(delegate()
{
Debug.Assert(i != 2);
});

t.Start();
threads.Add(t);
}

foreach (Thread thread in threads)
thread.Join();

Posting without reading any responses... "i" is captured and only has a
single "instance", so the assertion will fail if the thread executes
after the loop has "finished".

The solution:

List<Threadthreads = new List<Thread>();
for (int i = 0; i < 2; i++)
{
int j=i; // THIS IS THE CHANGE
Thread t = new Thread(delegate()
{
Debug.Assert(j != 2); // AND THIS
});

t.Start();
threads.Add(t);
}

foreach (Thread thread in threads)
thread.Join();

There's a new instance of "j" each time we go round the loop.
Or:
for (int i = 0; i < 2; i++)
{
Thread t = new Thread((ParameterizedThreadStart)delegate(object
y){ Debug.Assert((int)y != 2); });
t.Start(i);
threads.Add(t);
}

Or in C# V3 :
for (int i = 0; i < 2; i++)
{
Thread t = new Thread(y = { Debug.Assert((int)y != 2); });
t.Start(i);
threads.Add(t);
}
Willy.

Oct 24 '07 #12
Kalpesh <sh*********@gmail.comwrote:

<snip>
Could you explain, what is the problem with having to introduce j as a
temp. variable?
What is the problem with the original code (without introduction of
temp. variable inside the loop)?
It's not really a concurrency issue - it's an anonymous method issue.
The two new threads (and the continuing method) are all still using the
same variable.

See http://pobox.com/~skeet/csharp/csharp2/delegates.html for more -
look at the last section (captured variables)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Oct 24 '07 #13
I'm not sure that Sleep nor a loop would help here - really I suspect
all you need is:

for (int i = 0; i < 2; i++)
{
int j = i;
Thread t = new Thread(delegate()
{
Debug.Assert(j != 2);
});
t.Start();
threads.Add(t);
}

By 1.1 standards it looks the same, but j should (IIRC) now be scoped
(and hence captured) *inside* the loop. On each successive loop, the j
is completely different. Without the capture, of course, there is only
a single j declared on the stack at the top of the method... gotta
love capture ;-p

Marc

Oct 24 '07 #14
ahh, frick; sorry Jon - I didn't see your (scarily similar) post.
Deferred posting... oops and apols...

Oct 24 '07 #15
Marc Gravell wrote:
I'm not sure that Sleep nor a loop would help here - really I suspect
all you need is:
Help with what? The post to which I replied asked if there was a way to
_ensure_ that the two different versions of the code behaved
differently. I don't know why he's unable to reproduce a difference
without changing the samples; assuming he's running on Windows, it's
hard to imagine a scenario where the thread creating the other threads
gets preempted before the i loop exits.

But taking as granted his statement is true and he does in fact have
trouble seeing the difference, there are ways to hack up the code so
that the timing is more deterministic.

Please don't think that the post to which you replied was intended to
address the original issue. My comments there are _strictly_ with
respect to manipulating the code so that it fails in a more obvious,
reproducible way.

Pete
Oct 24 '07 #16
AJ

As a follow-on question... where does variable i 'live'. It's local and
a value type, so lives on the local stack...

So... remove the thread.Join() and make the threads take a little longer
e.g.

new Thread( delegate() { Thread.Sleep(5000); Debug.Assert(i!=2); }

The original method will have completed before the thread runs its code.
So where is the 'i' that it's referencing? Won't the stack have changed
by then?


In article <e6**************@TK2MSFTNGP02.phx.gbl>, cm******@yahoo.com
says...
I hit this bug last night in some test code I had written. It took a few
minutes to figure out what the root cause was, and it left me thinking,
"Wow. That was an interesting one that doesn't come up very often!".

So, for fun, who sees the bug and can explain why it's happening?

List<Threadthreads = new List<Thread>();
for (int i = 0; i < 2; i++)
{
Thread t = new Thread(delegate()
{
Debug.Assert(i != 2);
});

t.Start();
threads.Add(t);
}

foreach (Thread thread in threads)
thread.Join();

--
Chris Mullins
Oct 25 '07 #17
As a follow-on question... where does variable i 'live'. It's local
and
a value type, so lives on the local stack...
Nope, it doesn't live on the stack - it is "captured", so it lives as
a field on an object that the C# compiler creates for you. The rules
for the scoping of each "captured" variable is quite tricky... but but
*conceptually* what we are talking about (without using captures)
would be comparable to the following (although the compiler implements
it differently):

class SomeObject {
int i;
void SomeMethod() {
Debug.Assert(i != 2);
}
}
....
SomeObject obj = new SomeObject(); // obj instance is managed
for(int tmp = 0; tmp < 2; tmp ++) { // tmp lives on the stack
obj.i = tmp; // i lives on obj
Thread t = new Thread(obj.SomeMethod);
}

note that there is only a single "obj", and hence all share an "i".
Now compare to the version with a "j" introduced (see my other post in
this topic):

class SomeOtherObject {
int j;
void SomeOtherMethod() {
Debug.Assert(j != 2);
}
}
....
for(int i = 0; i < 2; i++) { // i lives on the stack
SomeOtherObject obj = new SomeOtherObject(); // obj instance is
managed
obj.j = i; // j lives on obj
Thread t = new Thread(obj.SomeOtherObject);
}

in this latter case, each loop iteration gets a different object, and
hence a different "j"

Please note: I have simplified the behavior to make a simple example.

Marc
Oct 25 '07 #18
On Oct 25, 10:47 am, AJ <no...@nowhere.comwrote:
As a follow-on question... where does variable i 'live'. It's local and
a value type, so lives on the local stack...
Well, it's only *sort* of a local variable. It's actually a captured
variable, and will live on the heap. It's the fact that it's captured
that makes the whole thing confusing.

Jon

Oct 25 '07 #19
Chris Mullins [MVP - C#] wrote:
Your explination is dead on, but the boxing / byref behavior of the
variable passed into the Closure is what made this code behavie in a way
other than was expected. I was expecting the int (a value type) to be
passed in by value, and therefore not change...
Actually, this functionality is much more useful. Besides the explanations
given here, this page may be interessting to you:

http://en.wikipedia.org/wiki/Closure_(computer_science)

Regards,

Mads

--
Med venlig hilsen/Regards

Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo
Dydensborg
Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77
34
Oct 29 '07 #20

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

16
by: aurora | last post by:
Hello! Just gone though an article via Slashdot titled "The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software" http://www.gotw.ca/publications/concurrency-ddj.htm]. It argues...
3
by: Suzanne | last post by:
Hi All I'm having problems getting my data adapter to throw a concurrency exception with an INSERT command. I want to throw a concurrency exception if an attempt is made to enter a row into...
4
by: Bob | last post by:
While testing my my program I came up with a consistency exception. My program consists of three datagridviews, One called dgvPostes which is the parent grid and its two children,one called...
7
by: William E Voorhees | last post by:
I'm updating an Access database in a windows multi-user environment. I'm using disconnected data I read data from an Access Data table to a data object I update the data object from a...
3
by: John | last post by:
Hi I have a vs 2003 winform data app. All the data access code has been generated using the data adapter wizard and then pasted into the app. The problem I have is that I am getting a data...
19
by: Chris Mullins [MVP - C#] | last post by:
I hit this bug last night in some test code I had written. It took a few minutes to figure out what the root cause was, and it left me thinking, "Wow. That was an interesting one that doesn't come...
5
by: John | last post by:
Hi I have developed the following logic to handle db concurrency violations. I just wonder if someone can tell me if it is correct or if I need a different approach.Would love to know how pros...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.