348170 - Browser crash on http://dehnamaki.blogfa.com/post-47.aspx [@ nppl3260.dll]

Status: RESOLVED WORKSFORME

(Plugins Graveyard :: RealPlayer (Real), defect)

Description

[(no longer active)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060710 Firefox/2.0b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060710 Firefox/2.0b1

It seems that whenever I go to http://dehnamaki.blogfa.com/post-47.aspx, the browser crashes.  See the crash report incidents TB21961128H, TB21952593Y, TB21944063K, TB21943344Y, TB21943280M.

Reproducible: Always

Steps to Reproduce:
1. Go to http://dehnamaki.blogfa.com/post-47.aspx
2. Watch the browser crash.




about:buildconfig

Build platform
target
i586-pc-msvc

Build tools
Compiler 	Version 	Compiler flags
$(CYGWIN_WRAPPER) cl 	12.00.8804 	-TC -nologo -W3 -Gy -Fd$(PDBFILE)
$(CYGWIN_WRAPPER) cl 	12.00.8804 	-TP -nologo -W3 -Gy -Fd$(PDBFILE)

Configure arguments
--enable-application=browser --enable-update-channel=beta --enable-official-branding --enable-optimize --disable-debug --disable-tests --enable-static --disable-shared --enable-svg --enable-canvas --enable-update-packaging

Comment 1

[Martijn Wargers (dead)]

Realplayer is involved with the crash.

I see this code in the page:
<EMBED src="https://www.sharemation.com/looty/nobahar.wma"
type=audio/x-pn-realaudio-plugin 
controls="controlpanel"
width=149 height=24  autostart="true" loop="-1" >

Reporter, what version of realplayer do you use?
You might want to upgrade to the newest version and see if that solves the crash.

Comment 2

[(no longer active)]

Yeah, this was a problem with Real Player.  As it appears, its installation was corrupted, and now that I've reinstalled RealOne Player 2, it's working.

Anyway, I don't know what Mozilla's policy is with regards to such problems, but I think it would be nice if Firefox doesn't crash upon a problem in a 3rd part application.  I have not checked the code, but wrapping the calls to external plugins in __try/__except blocks which handle Win32 structured exceptions such as an Access Violation should circumvent such problems (on the Win32 platform, that is).  Is that an option, or is such a mechanism already implemented?

Comment 3

[Martijn Wargers (dead)]

(In reply to comment #2)
> Yeah, this was a problem with Real Player.  As it appears, its installation was
> corrupted, and now that I've reinstalled RealOne Player 2, it's working.

So that means this is not a bug in Mozilla, right? Can I mark this bug worksforme, then?

> Anyway, I don't know what Mozilla's policy is with regards to such problems,
> but I think it would be nice if Firefox doesn't crash upon a problem in a 3rd
> part application.  I have not checked the code, but wrapping the calls to
> external plugins in __try/__except blocks which handle Win32 structured
> exceptions such as an Access Violation should circumvent such problems (on the
> Win32 platform, that is).  Is that an option, or is such a mechanism already
> implemented?

I think that is bug 156493. If you could write a patch for that bug, that would be really helpful.

Comment 4

[Adam Guthrie]

The Real Media Player plug-in is crashing you.

Incident ID: 21952593
Stack Signature	nppl3260.dll + 0x4341 (0x61544341) a4ac7282
Product ID	Firefox2
Build ID	2006071020
Trigger Time	2006-08-09 11:17:20.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	nppl3260.dll + (00004341)
URL visited	http://dehnamaki.blogfa.com/post-47.aspx
User Comments	
Since Last Crash	103 sec
Total Uptime	876234 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
nppl3260.dll + 0x4341 (0x61544341)
nppl3260.dll + 0xad6c (0x6154ad6c)
nsPluginHostImpl::InstantiateEmbeddedPlugin  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp, line 3493]
nsObjectFrame::InstantiatePlugin  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/generic/nsObjectFrame.cpp, line 1366]
nsObjectFrame::Reflow  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/generic/nsObjectFrame.cpp, line 1239]
nsLineLayout::ReflowFrame  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/generic/nsLineLayout.cpp, line 996]
nsBlockFrame::ReflowInlineFrame  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/generic/nsBlockFrame.cpp, line 4209]
nsBlockFrame::DoReflowInlineFrames  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/generic/nsBlockFrame.cpp, line 3862]
nsBlockFrame::ReflowInlineFrames  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/generic/nsBlockFrame.cpp, line 3744]
nsBlockFrame::ReflowLine  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/generic/nsBlockFrame.cpp, line 2712]
nsBlockFrame::ReflowDirtyLines  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/generic/nsBlockFrame.cpp, line 2272]
nsBlockFrame::Reflow  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/generic/nsBlockFrame.cpp, line 904]
nsContainerFrame::ReflowChild  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/generic/nsContainerFrame.cpp, line 905]
nsTableCellFrame::Reflow  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/tables/nsTableCellFrame.cpp, line 858]
nsContainerFrame::ReflowChild  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/generic/nsContainerFrame.cpp, line 905]
nsTableRowFrame::IR_TargetIsChild  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/tables/nsTableRowFrame.cpp, line 1227]
nsTableRowFrame::IncrementalReflow  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/tables/nsTableRowFrame.cpp, line 1111]
nsTableRowFrame::Reflow  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/tables/nsTableRowFrame.cpp, line 1410]
nsContainerFrame::ReflowChild  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/generic/nsContainerFrame.cpp, line 905]
nsTableRowGroupFrame::IR_TargetIsChild  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/tables/nsTableRowGroupFrame.cpp, line 1641]
nsTableRowGroupFrame::IncrementalReflow  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/tables/nsTableRowGroupFrame.cpp, line 1325]
nsTableRowGroupFrame::Reflow  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/tables/nsTableRowGroupFrame.cpp, line 1229]
nsContainerFrame::ReflowChild  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/generic/nsContainerFrame.cpp, line 905]
nsTableFrame::IR_TargetIsChild  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/tables/nsTableFrame.cpp, line 2939]
nsTableFrame::IncrementalReflow  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/tables/nsTableFrame.cpp, line 2676]
nsTableFrame::Reflow  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/tables/nsTableFrame.cpp, line 1933]
nsContainerFrame::ReflowChild  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/generic/nsContainerFrame.cpp, line 905]
nsTableOuterFrame::OuterReflowChild  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/tables/nsTableOuterFrame.cpp, line 1317]
nsTableOuterFrame::IR_InnerTableReflow  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/tables/nsTableOuterFrame.cpp, line 1658]
nsTableOuterFrame::IR_TargetIsInnerTableFrame  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/tables/nsTableOuterFrame.cpp, line 1423]
nsTableOuterFrame::IR_TargetIsChild  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/tables/nsTableOuterFrame.cpp, line 1405]
nsTableOuterFrame::IncrementalReflow  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/tables/nsTableOuterFrame.cpp, line 1374]
nsTableOuterFrame::Reflow  [c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_
...

Comment 5

[timeless]

(In reply to comment #2)
we *do* use SEH in plug-in code. you're welcome to read the code if you need pointers just ask.

Comment 6

[(no longer active)]

(In reply to comment #3)
> So that means this is not a bug in Mozilla, right? Can I mark this bug
> worksforme, then?

Hmm, actually I think that this *is* a bug in Mozilla.  The AV was not initiated by Mozilla's code, but the plugin code should be able to handle plugin crashes without taking down the whole browser.  I think we should make this bug dependent on bug 156493.

> I think that is bug 156493. If you could write a patch for that bug, that
> would be really helpful.

Yeah, I'm willing to put some time on this.  Right now I'm trying to study nspluginwrapper's code <http://www.gibix.net/projects/nspluginwrapper/>.  But I'm afraid I only have enough knowledge to be able to help in Win32 platform's implementation.

Comment 7

[(no longer active)]

(In reply to comment #5)
> we *do* use SEH in plug-in code. you're welcome to read the code if you need
> pointers just ask.

I'm downloading the code right now.  I need help in two major areas, as I'm completely new to Mozilla's source code.

1. Is there any documentation on the source code structure, as well as specific components of the source code (like the plugin loader/API) or is the code considered to be the only documentation available?  What is the recommended method for someone who already knows C++ pretty well to jump in the code?

2. Is there a quick-start howto or something like that on XPCOM?  I know COM on Win32 pretty well, and I understand that there are similarities between the two, so if there is any howto to get someone who knows M$ COM started with XPCOM, that would be great!

Thanks!

Comment 8

[timeless]

i'd request you not look at that wrapper. i don't want to think about that gpl code while you work on this. i presume ispiked will get you the refs.

in general, http://lxr.mozilla.org or http://landfill.mozilla.org/mxr-test/ are your best starting points.

the cross references are your friends.

Comment 9

[Adam Guthrie]

Actually, I'm not quite sure where this code lives. timeless will have to help you with this one.

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

I'm really not a fan of continuing program execution after an access violation... how do you know that the crash was not in the middle of updating a data structure which is now corrupted?

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

(hm, I think that was 7 comments late or so)

Comment 12

[timeless]

look for NS_TRY_SAFE_CALL_RETURN and NS_TRY_SAFE_CALL_VOID.

note that while biesi's right in general that there's nothing safe about continuing, as a user, i want a chance to use, retrieve, or otherwise save my data. as long as I'm told that I've already crashed I don't mind a temporary recovery.

Comment 13

[(no longer active)]

(In reply to comment #12)

I looked up NS_TRY_SAFE_CALL_RETURN and NS_TRY_SAFE_CALL_VOID.  They use try{}catch(...){} blocks.  Under the Visual C++ environment (which is, IINM, the supported compiler for the Win32 platform), the semantics of try{}catch(...){} depends upon the /EH compiler flag.

By default, the /EHs flag is in effect, which means that the compiler will only catch "synchronous" exception (that means, only the exceptions generated by the throw statement.)  The mode /EHa means that the compiler will catch "asynchronous" exceptions as well.  This causes the compiler to expect every instruction to be able to cause a (hardware) exception.  Check out <http://msdn2.microsoft.com/en-us/library/7f10tsf4.aspx> for a mode detailed explanation.

If the code is compiled with /EHa, then the compiler will catch an Access Violation, Division by Zero, etc. in the try{}catch(...){} block.  Otherwise, these exceptions go unhandled, and eventually lead to the whole app taked down by the OS.

Now, a "grep -rn /EH *" in the Mozilla source tree turns out empty, which means that the synchronous model is being used, and the try{}catch(...){} block does not catch the exception (that is the reason of the crash I had observed.)

Other than adding /EHa to the compiler flags, there is one more way to handle this situation: SetUnhandledExceptionFilter() API <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/setunhandledexceptionfilter.asp>.  This call adds an exception handler for those exceptions which are not handled (and are to be passed to the OS).  The problem with this method is we need to have access to the plugin's source file, because the only thing that can be done in an unhandled exception filter about an exception such as an AV is correcting the problem, and then retrying execution.  Clearly that is not an option.

So, I think the fix is compiling the source (at least, those which use the NS_TRY_SAFE_CALL_RETURN and NS_TRY_SAFE_CALL_VOID macros) with /EHa.  Of course __try/__except blocks can be used to the same effect.  AFAIK there's no gcc equivalent for either of these two (though I may be wrong here), so if any compiler other than VC++ is supported for the Win32 platform, we need to fix specific fixes for those platforms as well.

Any ideas?

Comment 14

[(no longer active)]

(In reply to comment #10, and partly comment #12)

Take a look at lines 75-77 and 96-98 of modules/plugin/base/src/nsPluginSafety.h.  I'm not familiar enough with the code to judge, but if the kCPluginManagerCID service is always implemented, and HandleBadPlugin() unloads the plugins (which the nsPluginHostImpl::HandleBadPlugin() implementation in modules/plugin/base/src/nsPluginHostImpl.cpp:6165 does not seem to do that), then I think that continuing after an AV in plugin is fairly safe, provided that the plugin only accesses Mozilla modules/components through well defined API, and does not manipulate its internal structures directly.

However, if the exception handling mechanism (see comment #13) is used, because of stack unwinding, chances are the program is left in a better state.

Comment 15

[timeless]

the logic is handled by
ENABLE_CXX_EXCEPTIONS
http://landfill.mozilla.org/mxr-test/seamonkey/source/config/rules.mk#229
 229 ifdef ENABLE_CXX_EXCEPTIONS
 230 ifdef GNU_CC
 231 CXXFLAGS                += -fexceptions
 232 else
 233 ifeq (,$(filter-out 1200 1300 1310,$(_MSC_VER)))
 234 CXXFLAGS                += -GX
 235 else
 236 CXXFLAGS                += -EHsc
 237 endif # _MSC_VER
 238 endif # GNU_CC
 239 endif # ENABLE_CXX_EXCEPTIONS

afaik setunhandled is not going to work. we don't have some random place to resume and i don't want to teach something stack crawling or marking. i could be wrong, but it seems way too complicated/intricate.

the articles i can find don't explain what "previous version" means when its says that things defaulted to what we wanted.

Unfortunately the choice of GX appears to have been based on warren and a tree that didn't build or was too noisy, the checkin is part of an unrelated change set and references a bug i can't find (bugscape?)

Can you possibly figure out which (microsoft) compilers actually like EHa. While msdn is great at listing supported OSs, I haven't learned how to determine supported compilers.

Comment 16

[(no longer active)]

> the logic is handled by ENABLE_CXX_EXCEPTIONS
> http://landfill.mozilla.org/mxr-test/seamonkey/source/config/rules.mk#229
> 229 ifdef ENABLE_CXX_EXCEPTIONS
> 230 ifdef GNU_CC
> 231 CXXFLAGS                += -fexceptions
> 232 else
> 233 ifeq (,$(filter-out 1200 1300 1310,$(_MSC_VER)))
> 234 CXXFLAGS                += -GX
> 235 else
> 236 CXXFLAGS                += -EHsc
> 237 endif # _MSC_VER
> 238 endif # GNU_CC
> 239 endif # ENABLE_CXX_EXCEPTIONS
> 
> afaik setunhandled is not going to work. we don't have some random place to
> resume and i don't want to teach something stack crawling or marking. i could
> be wrong, but it seems way too complicated/intricate.

Yeah.  It's practically impossible to use without specialized support from plugins, and even then it's a daunting task.

> the articles i can find don't explain what "previous version" means when its
> says that things defaulted to what we wanted.

Well, since VC6 onwards (which includes VC 6, 7, 7.1, and 8), -GX has been equivalent to -EHsc, and in VC8, it's being deprecated.  I don't remember previous VC versions, but they're not supported anyway.

> Unfortunately the choice of GX appears to have been based on warren and a tree
> that didn't build or was too noisy, the checkin is part of an unrelated change
> set and references a bug i can't find (bugscape?)

I think we should compile the code with -EHa.  As a general rule, I always compile my code with this option.

> Can you possibly figure out which (microsoft) compilers actually like EHa.
> While msdn is great at listing supported OSs, I haven't learned how to
> determine supported compilers.

Like I said, anything later than VC6 (inclusive) does support -EHa.  Check out <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_core_.2f.eh.asp>.  By the way, note that we don't want -EHc (it causes the compiler to assume extern "C" functions don't throw exceptions).  So, I guess the safe solution is -EHac-.

Comment 17

[timeless]

please fix your browser to not screw with the product/component fields.

i appreciate your help, and will post a patch shortly, but stepping on my work doesn't help :(.

Comment 18

[timeless]

Attachment: patch per [e-mail]

sounds good to me. btw, could i perhaps interest you in helping us to sprinkle SEH magic around our printing code? we sorely need it. i'll gladly find someone to help you set up a build environment or whatever it takes.

Comment 19

[(no longer active)]

timeless,

Sorry about the product/component fields.  I did not realize this change (and was in fact puzzled why you had to change it in the first place.  (Maybe I need to set up my account to CC me on my own edits as well...)

The patch looks good to me.  I'll be glad to help you with other SEH (or Win32 platfrom related) stuff.  Please let me know the bug IDs (if any) or give me some info on the problem.

Also, I desperately need build environment setup help.  I've been trying to setup a VC8 build environment on Windows, to no avail.  I've not been able to build it with gcc (mingw) as well.  :-(

Comment 20

[Christian :Biesinger (don't email me, ping me on IRC)]

why not use SEH if you want to catch access violations? this is an abuse of try..catch IMO.

Also, what makes you sure that what caused the crash is not a mozilla function that was called by the plugin? that makes your analysis in comment 14 wrong, because the mozilla function could have crashed in the middle of updating a data structure.

Comment 21

[(no longer active)]

(In reply to comment #20)
> why not use SEH if you want to catch access violations? this is an abuse of
> try..catch IMO.

I don't agree.  First of all, SEH in C++ requires special attention.  Mainly, you can't use __try/__except blocks in functions with local object instances, because SEH stack unwinding does not call C++ objects dtors.  So, you need a wrapper function, which is not trivial (though possible) to implement using the NS_TRY_SAFE_CALL_RETURN and NS_TRY_SAFE_CALL_VOID macros (we don't want to change their semantics, do we?).  In addition, in VC, C++ exceptions are also implemented using SEH, and if we want, we can use _set_se_translator() <http://msdn2.microsoft.com/en-us/library/5z4bw5h5.aspx> to convert a structured exception to a C++ one.  But with the case of NS_TRY_SAFE_CALL_RETURN and NS_TRY_SAFE_CALL_VOID, that's not necessary.

> Also, what makes you sure that what caused the crash is not a mozilla function
> that was called by the plugin? that makes your analysis in comment 14 wrong,
> because the mozilla function could have crashed in the middle of updating a
> data structure.

Hmm, check out comment #1, and crash report incidents TB21961128H, TB21952593Y,
TB21944063K, TB21943344Y, TB21943280M.  The crash happened inside nppl3260.dll, which is, IINM, a Real Player plugin component.  The focus of this bug is making sure such errors in *plugin code* don't cause the crash of the whole browser.  If the crash happens inside Mozilla code, then it's a bug which should be fixed separately.

Comment 22

[Christian :Biesinger (don't email me, ping me on IRC)]

ok, I guess my comments are really a few years late, so go on with that patch I guess. But I still think it is a very bad idea to make try..catch catch access violations.

> The focus of this bug is
> making sure such errors in *plugin code* don't cause the crash of the whole
> browser. 

the code can't tell where the crash happened though.

Comment 23

[(no longer active)]

(In reply to comment #22)
> the code can't tell where the crash happened though.

Sure it can.  Module nppl3260.dll, offset 0x4341.  This is the address of the instruction which caused the access violation.  So the faulty code is inside the plugin, not inside Mozilla.

Comment 24

[Christian :Biesinger (don't email me, ping me on IRC)]

the code does not catch just that error though. it catches every crash that happens while calling a plugin function.

Comment 25

[(no longer active)]

(In reply to comment #24)
> the code does not catch just that error though. it catches every crash that
> happens while calling a plugin function.

Well, only those calls through plugin functions that are made within a try{}/catch(...){} block (and they should be, because Mozilla's code is not supposed to deal with exceptions, right?).

Comment 26

[Christian :Biesinger (don't email me, ping me on IRC)]

I guess. I just find it rather risky to continue after an in-process crash.

Comment 27

[timeless]

Comment on attachment 233455 [details] [diff] [review]
patch per [e-mail]

this was a design decission. we toss up a dialog when it happens. users can ignore the crash at their own risk

Comment 28

[(no longer active)]

Attachment: Correction to attachment #233455

This patch corrects a small problem in attachment #233455 [details] [diff] [review], which prevented the build process because of an unmatched endif block.

Comment 29

[Martijn Wargers (dead)]

Is the patch still relevant?

Comment 30

[timeless]

yes.

http://mxr.mozilla.org/mozilla-central/search?string=EHsc&find=rules.mk

please get jst to review it.

Comment 31

[Martijn Wargers (dead)]

jst, can you review the patch?

Comment 32

[Johnny Stenback (:jst)]

I don't think we should change lowlevel exception handling this late in the game, if ever. The real solution to this problem is to run plugins in their own process, and we're seriously starting to look into that in the near future.

Comment 33

[Johnny Stenback (:jst)]

Comment on attachment 235083 [details] [diff] [review]
Correction to attachment #233455 [details] [diff] [review]

Clearing review requests, and this is probably obsolete by now given that we have out of process plugins, even if they're not enabled by default at this moment.

Comment 34

[RNicoletto]

The testcase page has no embedded Real Media content anymore and https://www.sharemation.com/looty/nobahar.wma does not exist anymore.

Is there any reproducible testcase for this bug?

Comment 35

[(no longer active)]

Unfortunately, no.

Comment 36

[Martijn Wargers (dead)]

Real plugins are crashing all the time for me, but I guess that is now a problem of the Realplayer itself.