1005487 - Firefox 29 doesn't exit when using "clear history when Firefox closes" is turned on

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[Rich Messeder]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140421221237

Steps to reproduce:

Two separate things that seem linked
1 Switch twixt Private and not Private browsing
2 Selected to delete offline data when Firefox closes


Actual results:

1. Firefox crashes and remains in memory. Task Manager required to kill.
2. On this page
http://www.mathworks.com/help/matlab/ref/strcat.html
Expand/Collapse doesn't work when these problems occur. I think that this problem is related to Offline Work Data, and the in-memory crash is related to toggling Private mode.


Expected results:

I am surprised that Firefox installed as a 32-bit app... I thought it would default to 64-bit on this Windows 7 Pro x64 system.
Firefox should exit when is closes, not hang in memory.

Comment 1

[:Gijs (he/him)]

(In reply to Rich Messeder from comment #0)
> User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
> Firefox/29.0 (Beta/Release)
> Build ID: 20140421221237
> 
> Steps to reproduce:
> 
> Two separate things that seem linked
> 1 Switch twixt Private and not Private browsing
> 2 Selected to delete offline data when Firefox closes
> 
> 
> Actual results:
> 
> 1. Firefox crashes and remains in memory. Task Manager required to kill.

Dumb question from me: It's possible that deleting offline data will take a long time. Are you sure that's not the cause of it staying in memory? How long have you waited?

Comment 2

[Rich Messeder]

I have not timed it. I first became aware of the problem when I would try to start an instance of Firefox quite some time after I had "closed" it earlier. Then I got (get) a dialog saying that Firefox is still running, and I can't start it again until I close the running instance. The same error occurs when I toggle private mode... Firefox used to just shut down and restart... now, it shuts down, but never restarts. I am open to the idea that it is somehow my system, but my system is otherwise stable, and Firefix worked consistently and reliably up to the last upgrade.

Comment 5

[:Gijs (he/him)]

Quite a number of dupes over the past couple of days. Tim, do you know whether this is related to some of the recent session restore changes and/or who could look into this?

Comment 6

[Tim Taubert [:ttaubert] (inactive)]

David, this sounds a lot like a problem with AsyncShutdown? Although this has been introduced for sessionstore with Firefox 27. Any ideas?

Comment 7

[David Teller [:Yoric] - still alive but not very active]

That's a possibility.

Rich, could you try the following thing?
1. attempt to quit Firefox;
2. wait until Firefox realizes that it won't succeed at quitting and decides to crash (this should take between 1 minute and 2 minutes);
3. accept to send a crash report;
4. send us the url of the crash report (you'll be able to find it by opening page about:crashes).

Now if Firefox never decides to crash, it's probably not related to AsyncShutdown, and I have no clear idea on how to proceed.

Comment 8

[Rich Messeder]

Thanks to all for your responses... I started down this trail when the Expand | Collapse Java on this page
http://www.mathworks.com/help/matlab/ref/strcat.html
would not work.
It does work in IE 9.
Whilst working w the folks @ Mathworks to figure that out, I decided that the problem lay w Firefox.
======
Requested info
======
Options > Advanced > Data Choices > check all (only send crash report was checked).
Toggle Private mode OFF.
[Often, Firefox will stop | restart when I do this, but then crash when I next stop it.]
Wait 3 minutes.
@ ~ 2 minutes, saw a Busy cursor, which I don't usually see, but never a crash report dialog.
Task Manager > Kill firefox *32.
Start Firefox.
Toggle Offline Website Data
Stop Firefox.
Firefox exits memory.

Start Firefox.
Stop Firefox.
Firefox exits memory.

Start Firefox.
Check Firefox version. Says up to date.
Stop Firefox.
Firefox hangs in memory. Stopwatch started.
Killed firefox *32 @ 2:30.
No report dialog.

Start Firefox.
Clear Options > Privacy > Clear history...
Stop Firefox.
Firefox exits memory.

Start Firefox.
Toggle Private mode OFF.
Firefox hangs in memory. Stopwatch started.
Killed firefox *32 @ 2:30.
No report dialog.

Start Firefox.
Log into bugzilla. Tell my story ;-)
~R~

Comment 9

[Tim Taubert [:ttaubert] (inactive)]

While trying to reproduce this I hit bug 1006478 and filed it. It might be the same issue, maybe it's not.

Comment 10

[Rich Messeder]

I found this bug report from 2014-05-04
8413f3d9-0e9b-44af-946e-5a2672140504
I've also noted more Shockwave crashes of late, but I figure that is their problem, not Firefox's.
While I live on my own cutting edge (space plasma physicist), I often think, with repsect to many other things in my life, that we are on some not-well-managed mad dash to "something better" without any real reason for the urgency or the lack of polish. I still use an email program from 2006 because it works better than the newer stuff, and I still use a Palm Pilot because it does a better job of being a PIM/PDA than the new device that I bought to replace it.
I do like (prefer) the new look and feel of Firefox... just not the crashes ;-) It's nice that the new version eats less space per page than the older one, and even web pages seem to display 'better' but I can't put my finger on why I think so.
~R~

Comment 13

[Tim Taubert [:ttaubert] (inactive)]

I'm quite sure this is caused by bug 1006478, which is triggered by calling PageThumbsStorage.wipe() at shutdown and thus spawning an OS.File worker.

Comment 14

[Tim Taubert [:ttaubert] (inactive)]

A quick and simple fix here might be to just use nsIFile and wipe the storage directory synchronously when onClearHistory() is called while shutting down. Using AsyncShutdown might not be as easy, or would it?

Comment 15

[David Teller [:Yoric] - still alive but not very active]

Actually, it's not the OS.File worker, it's the PageThumbsWorker. The OS.File worker should now be pretty solid against shutdown problems. But yes, using a nsIFile should be the easiest (and most upliftable) solution for a quick fix.

Comment 16

[cdorlandi]

My bug report was rolled over to this report (comment 11) since I had 'clear files on logout' checked.  However, I turned that off last night and my wife is reporting that the problem has not gone away - Firefox is remaining alive but hidden when it is shut down.  FYI.

Comment 17

[cdorlandi]

Ignore comment 16.  It appears that I didn't clear the check box like I thought I did.  It is now remembering history and I will comment again only if it still has the problem.  Thanks for your efforts.

Comment 18

[David Teller [:Yoric] - still alive but not very active]

(In reply to David Rajchenbach Teller [:Yoric] (please use "needinfo?" - I'll be away on May 8th-12th) from comment #15)
> Actually, it's not the OS.File worker, it's the PageThumbsWorker. The
> OS.File worker should now be pretty solid against shutdown problems. But
> yes, using a nsIFile should be the easiest (and most upliftable) solution
> for a quick fix.

Once bug 985655 has landed, performing the wipe with the AsyncShutdown should be quite simple.

Comment 20

[Henrik Skupin [:whimboo][⌚️UTC+1]]

We are also seeing lots of broken shutdowns of Firefox for our Mozmill tests lately, especially when we are installing an add-on and restart the browser right after. Could that be related? Sometimes we also see an AsyncShutdown exception as described on bug 994658 comment 9. Here an excerpt:

> 05:00:43 *************************
> 05:00:43 A coding exception was thrown and uncaught in a Task.
> 05:00:43 
> 05:00:43 Full message: TypeError: worker is null
> 05:00:43 Full stack: post/</<@resource://gre/modules/osfile/osfile_async_front.jsm:355:9
> 05:00:43 TaskImpl_run@resource://gre/modules/Task.jsm:282:1
> 05:00:43 TaskImpl@resource://gre/modules/Task.jsm:247:3

Comment 21

[David Teller [:Yoric] - still alive but not very active]

(In reply to Henrik Skupin (:whimboo) from comment #20)
> We are also seeing lots of broken shutdowns of Firefox for our Mozmill tests
> lately, especially when we are installing an add-on and restart the browser
> right after. Could that be related? Sometimes we also see an AsyncShutdown
> exception as described on bug 994658 comment 9. Here an excerpt:
> 
> > 05:00:43 *************************
> > 05:00:43 A coding exception was thrown and uncaught in a Task.
> > 05:00:43 
> > 05:00:43 Full message: TypeError: worker is null
> > 05:00:43 Full stack: post/</<@resource://gre/modules/osfile/osfile_async_front.jsm:355:9
> > 05:00:43 TaskImpl_run@resource://gre/modules/Task.jsm:282:1
> > 05:00:43 TaskImpl@resource://gre/modules/Task.jsm:247:3

That doesn't look like an AsyncShutdown error. That looks like bug 995162.

Comment 22

[Tim Taubert [:ttaubert] (inactive)]

This will be fixed by bug 965309. I'll file a separate bug to use AsyncShutdown for PageThumbsStorage.wipe() to ensure thumbnails get actually wiped on shutdown.

Comment 23

[Sylvestre Ledru [:Sylvestre]]

Tracking because it seems to impact enough users.

Comment 24

[Arthur K. (he/him)]

Isn't all this bug a dupe of bug 970923?

Comment 25

[Tim Taubert [:ttaubert] (inactive)]

Well, the other bug specifically fixes the hang for workers and sync XHRs. This bug is more about the fact that we spawn the PageThumbsWorker on shutdown - we could work around that without fixing bug 970923. With that fixed however we'll probably just concentrate on bug 1008148 and close this one. So, maybe.

Comment 29

[Tim Taubert [:ttaubert] (inactive)]

Will be fixed by bug 965309.

Comment 32

[Arthur K. (he/him)]

I am seeing this happen even when "clear history when Firefox closes" is turned off on 30b7. The problem seems to be getting worse.

Comment 33

[Arthur K. (he/him)]

Sorry, slight error on my part. Private browsing mode was enabled and on first glance the "clear history when Firefox closes" box was unchecked. Not being in Private browsing mode and unchecking "clear history when Firefox closes" does allow proper shutdown. Apologies.

Comment 34

[Rich Messeder]

I've been sailing along, Windows 7 Pro x64, Firefox current, Private mode ON, Clear history OFF. Not many crashes. In the last 24 hours I have had to address internet modem, wireless router issues. That meant using Firefox to manage the modem and router as I configured them. I wound up changing the IP range several times as part of the configuration. Firefox crashed im memory (as above) each time. No messages. Just the error when I tried to start a new instance of Firefox.
~R~

Comment 35

[Floki]

I got the same issue:
Firefox doesn't close properly in about 50 % of cases. When closing firefox, the window closes but the process firefox.exe isn't terminated. When trying to open firefox again you got the error message "Firefox is already running, but not responding. To open a new window, you must first close the existing Firefox process, or restart your system." After terminating the process firefox.exe in the windows task manager, firefox can be started again.

Error only occurs when under "Options/Privacy/Use custom settings for history" at "Clear History when Firefox closes" the option "Browsing and Download History" is selected. 
All other options selected or not don't cause the issue.
I switched this option several times. When "Browsing and Download History" at "Clear History when Firefox closes" isn't selected, the error doesn't appear.

Reproducible regardless if "Remember my browsing history" and "Remember download history" are selected or not.
Reproducible: 
- after new installation of Firefox (Firefox 29.0.1 german, Windows7 64-bit)
- with different profiles, even with all addons disabled or running in safe mode
- with new profile with no addons or dictionaries installed
- with windows firewall turned off and deactivated antivirus program
- with hardware acceleration on and off

Comment 36

[David Teller [:Yoric] - still alive but not very active]

Note to people who encounter the issue: we believe that we have fixed it and the fix should be released as part of Firefox 30 beta 8, most likely on Wednesday or Thursday. If you can test it once it gets out, this would be great.

Comment 37

[John Hesling [:John99] (NeedInfo me)]

(In reply to David Rajchenbach Teller [:Yoric] (please use "needinfo?" - I'll be away on May 16th-23th) from comment #36)

I am tracking a few of the many threads on support.mozilla some individual threads have hundreds or thousands of views so no shortage of potential testers that will be pleased to revert to their original settings. Confirm the fix is on Beta and I will ask.

Comment 38

[Arthur K. (he/him)]

(In reply to David Rajchenbach Teller [:Yoric] from comment #36)
> Note to people who encounter the issue: we believe that we have fixed it and
> the fix should be released as part of Firefox 30 beta 8, most likely on
> Wednesday or Thursday. If you can test it once it gets out, this would be
> great.

After many attempts, I am struggling to repro the problem on 30b8. Looks promising.

Comment 39

[Rich Messeder]

Just a note to muddy the waters. Firefox 29.0.1 on Windows 7 Pro x64. Been running for weeks with Private checked, and Clear history NOT checked. No problems, as long as I didn't togle Private viewing. Yesterday I was surprised to find Firefox still in memory long after I closed it. Killed it with the Task Manager. Can't recall what I was doing before I closed Firefox and it remained in memory.

Comment 41

[John Hesling [:John99] (NeedInfo me)]

(In reply to John Hesling [:John99] from comment #37)
> ... Confirm
> the fix is on Beta and I will ask.
I am not noticing  much feedback at present but just mentioning what I have seen indicates that beta works for this issue e.g. https://support.mozilla.org/en-US/questions/997670?page=2#answer-584991

Comment 42

[David Teller [:Yoric] - still alive but not very active]

Thanks.

Comment 43

[Rich Messeder]

I have been running 30b8 (I think... Firefox does not say explicitly what beta version it is) for several days. I have been frequently toggling the settings that seemed linked to the problem:
Private viewing
Clear history when Firefox closes
Work offline

I have not seem a problem of any sort. I will continue running the beta until the public release of v30.
~R~

Comment 44

[Rich Messeder]

Firefox recently upgraded itself to 30RC1. I wasa smoothly sailing along until I hit the same problem that trigger my going down this road in the first place. See the start of this thread. I was on a mathworks.com Help page, and tried to expand an example. I could not. I unchecked Private and Clear History, and the exampls worked. I should run a few more tests, then update this. the tech support folks at mathworks did not think that either of these should stop the examples from working.

Comment 45

[Rich Messeder]

I testd every combo of Private, Clear History and Offline Website Data, all of which seemed to play a role in the problem as I first encountered it. Seemed to. Now I cannot activate the Help examples if I have Private checked. I don't know if this is a Firefox or Mathworks issue.

Also I have noticed that Firefox will sometimes not pop up to the front of all other apps when it is restarting. Seems like it should, but sometimes it comes up under the last app in use.

I also thought that I could edit my comment once I logged out of bugzilla and back in, but don't see how to do that.
~R~

Comment 46

[Arthur K. (he/him)]

(In reply to Rich Messeder from comment #44)
> Firefox recently upgraded itself to 30RC1. I wasa smoothly sailing along
> until I hit the same problem that trigger my going down this road in the
> first place. See the start of this thread. I was on a mathworks.com Help
> page, and tried to expand an example. I could not. I unchecked Private and
> Clear History, and the exampls worked. I should run a few more tests, then
> update this. the tech support folks at mathworks did not think that either
> of these should stop the examples from working.

It should soon update to "RC2" (actually just a rebuild) soon. I don't know that much changed between the RCs though.

Comment 47

[Lukas Blakk [:lsblakk] use ?needinfo]

There is a build #2 coming but it won't look different in the updated 'about'.  Have to wontfix this for FF30 as we are not close to having something to work with on this issue but also given comment 45 this seems to have morphed from the original STR.  Can you provide updated ones?

Comment 48

[Tim Taubert [:ttaubert] (inactive)]

Both bug 1008148 and bug 965309 have been fixed and uplifted to Firefox 30. Comment #44 and comment #45 seem to be completely unrelated issues that have nothing to do with the shutdown hang that this bug is about. Marking as fixed by the aforementioned bugs.

Comment 49

[Rich Messeder]

I have tested the problem in comment 44 and 45, and determined that the problem still exists. I'll start a new bug report.
~R~

Comment 50

[Arthur K. (he/him)]

(In reply to Rich Messeder from comment #49)
> I have tested the problem in comment 44 and 45, and determined that the
> problem still exists. I'll start a new bug report.
> ~R~

Have you by chance tried with FF31.b1?

Comment 51

[David Teller [:Yoric] - still alive but not very active]

(In reply to Rich Messeder from comment #49)
> I have tested the problem in comment 44 and 45, and determined that the
> problem still exists. I'll start a new bug report.
> ~R~

Please do. This seems to be an entirely unrelated bug.

Comment 52

[Rich Messeder]

I know what it is like to be unpopular ;-) Here's what happened. I posted a new bug report. 1023961 I got a nice reply that suggested I not file a bug report because Bugzilla is not a good place for end-user support. I followed the advice and reset Firefox, even though I had completely removed every trace I could find of Firefox during the beta testing. Sure enough, the problem went away. So I wondered what I possibly could have done to cause the above mentioned web pages to fail. I had not enabled anything in Firefox. Nonetheless (still reading folks?), I trundled on and changed Silverlight from "ask" to "enable", and continued to test. Testing consisted of toggling different options, closing Firefox, and linking to the problem page at MathWorks. I should point out that any page there acts the same. No problems.

Eventually, I not only recreated the problem, but I managed to get Firefox to crash just like this bug thread. It was resident for over 20 minutes after I closed it last time. I used the task manager to close it so that I could file this report. Dunno if I am simply abusing Firefox? What finally did the trick was toggling Remember browsing... and Remember search...

Now, not only did I crash Firefox (staying resident after closing), but I can't expand and collapse the examples.
~R~

Comment 53

[TheExplorer]

Well, being one of the first who encountered this issue ([url=https://bugzilla.mozilla.org/show_bug.cgi?id=1004476]bug 1004476[/url]), I'm still having this issue on Debian box at work with Firefox 30 release. The browser hang with the option to clear history upon closing. It happened not at once but on the second or third closing. I let Firefox some reasonable time before trying to open it up again. But alas :( Will try to reproduce it again on my home box and in Windows.

Comment 54

[TheExplorer]

Sorry, by the way someone has already started a new one: bug 1023964

Comment 55

[u279076]

Flagging for verification since this seems to be still reproducing for some users.

Comment 58

[Petruta Horea [:phorea], Desktop QA]

I could no longer reproduce the issue using Firefox 31 beta 8 and Aurora 32.0a2 2014-07-07 while we were able to see it on Firefox 29.0.1 having the pref "clear history on exit" enabled. 
The other issues seems unrelated to this bug. Also, there are no new forum discussions on this topic.

Marking as verified.

Comment 59

[Mertsch]

Apparently this issue is back with Fx 33.1. and 34 beta
When my cache size reaches it's automatic limit of 350MB the browser hangs frequently on shutdown (not always)

Comment 60

[David Teller [:Yoric] - still alive but not very active]

Does it crash or freeze?

Comment 61

[Mertsch]

It shuts down all visible components and then remains with <0.01 CPU usage as process

Comment 62

[David Teller [:Yoric] - still alive but not very active]

Normally, Firefox is designed so that such hangs eventually cause a crash after ~1 minute, and the crashes contain details about the hang. Can you confirm that this is the case for you?

Comment 63

[Mertsch]

(In reply to David Rajchenbach-Teller [:Yoric] (away until November 17th - use "needinfo") from comment #62)
> Normally, Firefox is designed so that such hangs eventually cause a crash
> after ~1 minute, and the crashes contain details about the hang. Can you
> confirm that this is the case for you?

I have this issue for some weeks now, sometimes more sometimes less frequent and Fx never crashed in that time after a given timeout. If I don't use Fx directly after it hangs in the background for hours.
But it seems there are crash report anyway

https://crash-stats.mozilla.com/report/index/a236d93b-8139-4483-a80b-4bbc22141123
https://crash-stats.mozilla.com/report/index/82ca0136-5643-46ca-96aa-2cfeb2141123
https://crash-stats.mozilla.com/report/index/6dd604c5-5687-46c5-aac5-071a22141123
https://crash-stats.mozilla.com/report/index/d124587d-1c6e-4084-b733-762db2141123
https://crash-stats.mozilla.com/report/index/9c4d6007-b9b5-440c-b163-7d5282141123
https://crash-stats.mozilla.com/report/index/ad9fa0bf-0f58-4db2-acb6-a053f2141123
https://crash-stats.mozilla.com/report/index/92c40fd2-fc51-4697-be6d-876c52141123

All seem to show the same symptom and are just a few out of the hundreds in my about:support list

Comment 64

[David Teller [:Yoric] - still alive but not very active]

Apparently, these crashes are unrelated to the issue at hand.

Comment 65

[Mertsch]

Maybe they are a result of killing the process.
If I look at the locked process, the Fx.exe remains in that Stack, and uses a few CPU cycles now and then

ntoskrnl.exe!KeWaitForMultipleObjects+0xc0a
ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x732
ntoskrnl.exe!KeWaitForMutexObject+0x19f
ntoskrnl.exe!PoStartNextPowerIrp+0xba4
ntoskrnl.exe!PoStartNextPowerIrp+0x1821
ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x93d
ntoskrnl.exe!KeWaitForMutexObject+0x19f
ntoskrnl.exe!NtWaitForSingleObject+0xde
ntoskrnl.exe!KeSynchronizeExecution+0x3a23
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x42a
ntdll.dll!RtlIsDosDeviceName_U+0x23a27
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwWaitForSingleObject+0x15
kernel32.dll!WaitForSingleObjectEx+0x43
kernel32.dll!WaitForSingleObject+0x12
xul.dll!NS_UnregisterXPCOMExitRoutine+0x60bf
xul.dll!NS_UnregisterXPCOMExitRoutine+0x60d4
xul.dll!??0_Mutex@std@@QAE@W4_Uninitialized@1@@Z+0x188672
MSVCR100.dll!_endthreadex+0x3a
nvd3dum.dll+0x3432e4
MSVCR100.dll!_endthreadex+0xe4
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36

Comment 66

[Mertsch]

Eh, sorry that the was the wrong stack trace (it's from MSVCR100.dll)
The correct Firefox.exe stack trace is this one

ntoskrnl.exe!KeWaitForMultipleObjects+0xc0a
ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x732
ntoskrnl.exe!KeWaitForMutexObject+0x19f
ntoskrnl.exe!PoStartNextPowerIrp+0xba4
ntoskrnl.exe!PoStartNextPowerIrp+0x1821
ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x93d
ntoskrnl.exe!KeWaitForMutexObject+0x19f
ntoskrnl.exe!NtWaitForSingleObject+0xde
ntoskrnl.exe!KeSynchronizeExecution+0x3a23
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x42a
ntdll.dll!RtlUniform+0x6e6
ntdll.dll!RtlCreateTagHeap+0xa7
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwWaitForSingleObject+0x15
kernel32.dll!WaitForSingleObjectEx+0x43
kernel32.dll!WaitForSingleObject+0x12
xul.dll!NS_GetXPTCallStub+0x49286
xul.dll!NS_NewLocalFile+0x34083

Comment 67

[Mertsch]

Attachment: Threads that keep running after Fx has been shut down

I have attached myself to the hanging process with Visual Studio and Mozilla Reference Server set up. This is the list of remaining threads (after about 30 minutes). Some of the worker thread did shutdown, but the main thread remains in the same stack trace.

Comment 68

[David Teller [:Yoric] - still alive but not very active]

Mertsch: Thanks for the detailed stack traces. Despite the same symptoms, this is a different bug. Could you open a new bug report and post the data over there? This will avoid confusing information from two unrelated bugs.

Comment 69

[Mertsch]

(In reply to David Rajchenbach-Teller [:Yoric] (hard to reach until January 10th - use "needinfo") from comment #68)

Will not do that as the issue seems to be gone since beta 1 of 35.0
If I re-encounter this issue I will do that. Thanks.