Last Comment Bug 388993 - Crash when opening a new tab [@ js_GetScriptLineExtent] [@ NSGetModule]
: Crash when opening a new tab [@ js_GetScriptLineExtent] [@ NSGetModule]
Status: NEW
[firebug-p5]
: crash
Product: Other Applications
Classification: Client Software
Component: Venkman JS Debugger (show other bugs)
: Trunk
: All All
: -- critical (vote)
: ---
Assigned To: Robert Ginda
:
:
Mentors:
: 402513 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-20 13:01 PDT by Chris Harrington
Modified: 2016-02-10 04:05 PST (History)
15 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Backtrace (3.93 KB, text/plain)
2007-07-20 13:02 PDT, Chris Harrington
no flags Details
More better crash log (26.43 KB, text/plain)
2007-07-23 13:17 PDT, Chris Harrington
no flags Details
Shared Library list (19.81 KB, text/plain)
2007-07-23 13:23 PDT, Chris Harrington
no flags Details
Commands requested (2.74 KB, text/plain)
2007-07-23 13:40 PDT, Chris Harrington
no flags Details
crash log from 2.0.0.9 / OS X Leopard (30.68 KB, text/plain)
2007-11-14 10:24 PST, MasterLeep
no flags Details

Description Chris Harrington 2007-07-20 13:01:06 PDT
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

See backtrace. Crash occurred after opening a new tab with Command-T. Got the beachball for a few seconds before the crash hit. Only had one page open (no tab bar) before the key combo was pressed. Was viewing http://www.woot.com , but never had an issue with it before.

Reproducible: Couldn't Reproduce




about:buildconfig

Build platform
target
powerpc-apple-darwin8.7.0

Build tools
Compiler 	Version 	Compiler flags
gcc-3.3 -arch ppc 	gcc version 3.3 20030304 (Apple Computer, Inc. build 1819) 	-Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -nostdinc -isystem /Developer/SDKs/MacOSX10.2.8.sdk/usr/include/gcc/darwin/3.3 -isystem /Developer/SDKs/MacOSX10.2.8.sdk/usr/include -F/Developer/SDKs/MacOSX10.2.8.sdk/System/Library/Frameworks -fpascal-strings -no-cpp-precomp -fno-common -I/Developer/SDKs/MacOSX10.2.8.sdk/Developer/Headers/FlatCarbon
g++-3.3 -arch ppc 	gcc version 3.3 20030304 (Apple Computer, Inc. build 1819) 	-fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -nostdinc -nostdinc++ -I/Developer/SDKs/MacOSX10.2.8.sdk/usr/include/gcc/darwin/3.3/c++ -I/Developer/SDKs/MacOSX10.2.8.sdk/usr/include/gcc/darwin/3.3/c++/ppc-darwin -I/Developer/SDKs/MacOSX10.2.8.sdk/usr/include/gcc/darwin/3.3/c++/backward -isystem /Developer/SDKs/MacOSX10.2.8.sdk/usr/include/gcc/darwin/3.3 -isystem /Developer/SDKs/MacOSX10.2.8.sdk/usr/include -F/Developer/SDKs/MacOSX10.2.8.sdk/System/Library/Frameworks -fpascal-strings -no-cpp-precomp -fno-common -fshort-wchar -I/Developer/SDKs/MacOSX10.2.8.sdk/Developer/Headers/FlatCarbon -I/usr/X11R6/include

Configure arguments
--target=powerpc-apple-darwin8.7.0 --with-macos-sdk=/Developer/SDKs/MacOSX10.2.8.sdk --enable-application=browser --enable-update-channel=release --enable-official-branding '--enable-optimize=-O2 -g' --disable-debug --disable-tests --enable-update-packaging --enable-static --disable-shared --enable-prebinding --enable-svg --enable-canvas
Build platform
target
i386-apple-darwin8.7.0

Build tools
Compiler 	Version 	Compiler flags
gcc-4.0 -arch i386 	gcc version 4.0.1 (Apple Computer, Inc. build 5250) 	-Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fpascal-strings -no-cpp-precomp -fno-common -I/Developer/SDKs/MacOSX10.4u.sdk/Developer/Headers/FlatCarbon
g++-4.0 -arch i386 	gcc version 4.0.1 (Apple Computer, Inc. build 5250) 	-fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fpascal-strings -no-cpp-precomp -fno-common -fshort-wchar -I/Developer/SDKs/MacOSX10.4u.sdk/Developer/Headers/FlatCarbon

Configure arguments
--target=i386-apple-darwin8.7.0 --with-macos-sdk=/Developer/SDKs/MacOSX10.4u.sdk --enable-application=browser --enable-update-channel=release --enable-official-branding '--enable-optimize=-O2 -g' --disable-debug --disable-tests --enable-update-packaging --enable-static --disable-shared --enable-svg --enable-canvas

I'm marking the severity as "Critical" since it meets the criteria of the software crashing. However, I've never before encountered this issue, so in practice it is a fairly minor issue.
Comment 1 Chris Harrington 2007-07-20 13:02:48 PDT
Created attachment 273145 [details]
Backtrace

Attaching backtrace.
Comment 2 Chris Blore 2007-07-22 12:12:27 PDT
I am unable to reproduce in Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a7pre) Gecko/2007072204 Minefield/3.0a7pre

Have you been able to reproduce this either? If not, please could you close the bug and mark it a WORKSFORME?

Thanks
Comment 3 Chris Harrington 2007-07-22 14:09:59 PDT
I have not been able to reproduce it, however, isn't this effectively a buffer overflow issue in js_GetScriptLineExtent? I'll leave it to you to close; as I stated in my report, I can't reproduce.
Comment 4 timeless 2007-07-23 05:05:30 PDT
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/js/src/jsscript.c&rev=3.151&mark=1687-1703#1686

no. it's crashing there, but the problem is elsewhere. usually the problem is that the script was freed or equivalent. there's no way that js_GetScriptLineExtent and similar functions can protect themselves from this.

picture this. you're Wile E Coyote, and you're twenty feet away from the ledge (off the edge of the cliff). You look down, you see you aren't standing on solid ground. What do you do? Answer: you fall. What else can you do? not much. You can only not fall *before* you run off the edge of the cliff, not after.
Comment 5 Chris Harrington 2007-07-23 07:03:40 PDT
That's a really good visual for a crash. ;)

So is there no point in submitting a crash bug with backtrace if one can't reproduce? I understand if there is no information other than "it crashed", but what can be included that would help with the diagnostic? I basically gave you everything I had (Backtrace, circumstances, and detailed build info) what else would make this a valuable bug?
Comment 6 timeless 2007-07-23 08:51:34 PDT
yes, i like it. i'll have to include it in the doc i'm writing.

crash bugs w/ backtraces can either be sufficient or frustrating. it's very hit or miss, and unless you're me there's not much chance in you knowing which it'll be. there's nothing wrong with filing bugs. filing them with back traces is a lot better than filing them w/o. the triagers are fairly good at spotting duplicates, patterns, etc.

really the only other thing that helps is steps to reproduce. when you don't have them, what you've included is the best we can get. Sometimes it's worth listing which extensions and plugins you have in case either of them have interesting traits. Note that for official builds, we don't really need build information (we can figure it out), build info is important if the build isn't one we made (and then the first thing we'll ask is for you to reproduce it with one we did make!).

I'm slowly writing http://docs.google.com/Doc?id=dhmd4jxt_58ftzb2h  (url might change, dunno). We'll see where it goes.
Comment 7 timeless 2007-07-23 08:54:58 PDT
Comment on attachment 273145 [details]
Backtrace

oh, one important thing!

if the build is one we made, on most platforms you can't use gdb to get a useful stack trace because we don't ship symbols which means what you'll see has nothing to do with what actually crashed. in these cases we request people use Talkback instead. (did you use gdb yourself or did this come from apple's crash reporter? -- normally on os x we do have symbols, but NSGetModule usually indicates a lack of symbols. Alternatively. Assuming most of the frames are correct, there's a section of apple crash reports indicating loaded modules. What module does it say is loaded around 0x01aeb000..0x01af0000?
Comment 8 Chris Harrington 2007-07-23 09:24:27 PDT
I used gdb myself. I'm also noting that in the build configuration, debug is explicitly disabled. I've never had talkback work on OS X. I'd love if it did...

I don't know how to answer your last question.
Comment 9 timeless 2007-07-23 12:58:26 PDT
the -g in '--enable-optimize=-O2 -g' gives it symbols.

did apple's crash reporter fire? if so there'd be a stack in Console.app's crashreporter logs.

info sharedlibrary would probably give the address (not sure how to get upper limit).
Comment 10 Chris Harrington 2007-07-23 13:17:02 PDT
Created attachment 273444 [details]
More better crash log

Aha. Missed the -g flag. Attaching firefox-bin.crash.log as generated by the Apple's crash reporter. Running "info sharedlibrary" didn't turn up any info documents, though I'm not sure that's what you meant.
Comment 11 Chris Harrington 2007-07-23 13:23:50 PDT
Created attachment 273449 [details]
Shared Library list

Oh, color me dumb. I didn't realize you were replying to what I said in comment #8. Running the command on this very instance of Firefox generates the attached.
Comment 12 timeless 2007-07-23 13:31:52 PDT
actually the format of apple's crash report tells me the things i want to know faster. (libraryname, start, stop).

how about:
ls -lh /Applications/Firefox.app/Contents/MacOS/*.dylib /Applications/Firefox.app/Contents/MacOS/components/*.dylib

something funny is going on. All the other libraries seem to have correct symbols. It almost looks like jsd doesn't. I'm wondering if it's from somewhere else.

Also, do |file libjsd.dylib; file libmozjs.dylib| (you need correct current working directory for these two)
Comment 13 Chris Harrington 2007-07-23 13:40:07 PDT
Created attachment 273455 [details]
Commands requested

Ask, and I shall execute.
Comment 14 Matthew Gertner 2007-09-26 11:01:59 PDT
I've had the same problem three times in the past 2 days on Windows. I have a minidump, and the stack looks identical to the one Chris has. Unfortunately symbols are gibberish as they tend to be in release mode. If the minidump can be of use please let me know. The problem isn't reproducible consistently.

I never had this problem before 2.0.0.7 so IMO it would be worth looking at what changed since 2.0.0.6 that might be the culprit.
Comment 15 Lorenz Froihofer 2007-09-26 23:05:39 PDT
I also experienced this problem some time ago (even before 2.0.0.7). However, due to bug #395478 I uninstalled the SwitchProxy extension. From this time on, I did not have this problem any more. You could check whether one of your extensions (SwitchProxy?) is causing this bug.

Moreover, you could try whether the problem also exists with a clean profile (see
<http://kb.mozillazine.org/Profile_manager> for how to create one).
Comment 16 Chris Harrington 2007-09-26 23:12:38 PDT
I do not use SwitchProxy, so I do not believe that was the root of the bug.
Comment 17 MasterLeep 2007-11-14 10:24:44 PST
Created attachment 288698 [details]
crash log from 2.0.0.9 / OS X Leopard

Here's a crash trace from 2.0.0.9 / Leopard, looks like the same crash.
Comment 18 MasterLeep 2007-11-14 10:31:58 PST
I also have two other stack traces for this crash - let me know if it would be useful to post them.  Of the eight times Firefox has crashed for me in the past two weeks, three of them are this bug.
Comment 19 Matthew Gertner 2007-11-16 08:58:11 PST
Another data point: this seems to happen every time I open a new tab (which for some reason on my machine takes a couple of seconds) and click in the FF search box before the tab opens. This is on Windows. On my Macs I don't have the problem at all.

I suspect this is the result of a particular combination of overlays. My extensions:

AllPeers 0.70.1
Firebug 1.05
FireFTP 0.97.1
Flashblock 1.5.4.1
ForecastFox 0.9.6
Live HTTP Headers 0.13.1

When I have time I'll do some experimentation to see if selectively disabling extensions fixes the problem.
Comment 20 Chris Harrington 2007-11-16 09:00:36 PST
Interesting common extensions:

Firebug
FireFTP
Live HTTP Headers

Don't know what versions they were when they were installed; had a major failure after this crash, started over, use different extensions.
Comment 21 MasterLeep 2007-11-16 11:53:20 PST
I also use Firebug, but I don't have any of the other extensions.
Comment 22 Matthew Gertner 2007-11-22 01:38:50 PST
I uninstalled Firebug and the problem instantly vanished (including the delay when opening a new tab). Unless someone is having the problem and does not have Firebug, I'd be inclined to say that it's the culprit.
Comment 23 Chris Harrington 2007-11-22 22:23:03 PST
Agreed; haven't re-installed Firebug since the crash, haven't had the issue. So is this technically a Firefox bug? Or an extension bug?
Comment 24 Jeremy Morton 2007-11-23 02:05:27 PST
Interesting.  But, as so many devs use Firebug, I think it maybe warrants some investigation by the Firefox devs to see whether it's a bug in Firefox functionality that Firebug is using, or something that needs to be in the Firebug codebase.
Comment 25 [:Aleksej] 2007-11-24 14:28:44 PST
I have had at least three crashes with this stack signature on GNU/Linux, at least two of them when browsing Wikipedia, after or when opening a new tab: TB38418757G, TB38419087H.

Some of the extensions I have installed right now are Firebug 1.05 (not enabled for the sites) and Live HTTP Headers 0.13.1.

Changing the OS and Platform to All.
Comment 26 timeless 2007-11-26 08:45:18 PST
I like the windows flavor better.

fun_apply is moderately interesting.

Incident ID: 38418757
Stack Signature	js_GetScriptLineExtent() 672df407
Product ID	Firefox2
Build ID	2007102514
Trigger Time	2007-11-24 14:08:44.0
Platform	LinuxIntel
Operating System	Linux 2.6.22-2-amd64
Module	libmozjs.so + (00075b29)
URL visited	
User Comments	
Since Last Crash	13 sec
Total Uptime	115 sec
Trigger Reason	SIGSEGV: Segmentation Fault: (signal 11)
Source File, Line No.	/builds/tinderbox/Fx-Mozilla1.8-release/Linux_2.4.21-27.0.4.EL_Depend/mozilla/js/src/jsscript.c, line 1668
Stack Trace 	
js_GetScriptLineExtent()  [mozilla/js/src/jsscript.c, line 1668]
JS_GetScriptLineExtent()  [mozilla/js/src/jsdbgapi.c, line 969]
jsd_GetScriptLineExtent()  [mozilla/js/jsd/jsd_scpt.c, line 475]
JSD_GetScriptLineExtent()  [mozilla/js/jsd/jsdebug.c, line 308]
jsdScript::jsdScript()  [mozilla/js/jsd/jsd_xpc.cpp, line 986]
jsdService::EnumerateScripts()  [mozilla/js/jsd/jsd_xpc.cpp, line 155]
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)()  [mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2168]
XPC_WN_CallMethod()  [mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1455]
js_Invoke()  [mozilla/js/src/jsinterp.c, line 1375]
js_Interpret()  [mozilla/js/src/jsinterp.c, line 3947]
js_Invoke()  [mozilla/js/src/jsinterp.c, line 1394]
nsXPCWrappedJSClass::CallMethod()  [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1453]
nsXPCWrappedJS::CallMethod()  [mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 468]
PrepareAndDispatch()  [mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp, line 100]
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)()  [mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2168]
XPC_WN_CallMethod()  [mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1455]
js_Invoke()  [mozilla/js/src/jsinterp.c, line 1375]
js_Interpret()  [mozilla/js/src/jsinterp.c, line 3947]
js_Invoke()  [mozilla/js/src/jsinterp.c, line 1394]
fun_apply()  [mozilla/js/src/jsfun.c, line 1696]
js_Invoke()  [mozilla/js/src/jsinterp.c, line 1375]
js_Interpret()  [mozilla/js/src/jsinterp.c, line 3947]
js_Invoke()  [mozilla/js/src/jsinterp.c, line 1394]
nsXPCWrappedJSClass::CallMethod()  [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1453]
nsXPCWrappedJS::CallMethod()  [mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 468]
PrepareAndDispatch()  [mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp, line 100]
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)()  [mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2168]
XPC_WN_CallMethod()  [mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1455]
js_Invoke()  [mozilla/js/src/jsinterp.c, line 1375]
fun_apply()  [mozilla/js/src/jsfun.c, line 1696]
js_Invoke()  [mozilla/js/src/jsinterp.c, line 1375]
js_Interpret()  [mozilla/js/src/jsinterp.c, line 3947]
js_Invoke()  [mozilla/js/src/jsinterp.c, line 1394]
nsXPCWrappedJSClass::CallMethod()  [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1453]
nsXPCWrappedJS::CallMethod()  [mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 468]
PrepareAndDispatch()  [mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp, line 100]
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)()  [mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2168]
XPC_WN_CallMethod()  [mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1455]
js_Invoke()  [mozilla/js/src/jsinterp.c, line 1375]
js_Interpret()  [mozilla/js/src/jsinterp.c, line 3947]
js_Invoke()  [mozilla/js/src/jsinterp.c, line 1394]
nsXPCWrappedJSClass::CallMethod()  [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1453]
nsXPCWrappedJS::CallMethod()  [mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 468]
PrepareAndDispatch()  [mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp, line 100]
nsDocLoader::FireOnStateChange()  [mozilla/uriloader/base/nsDocLoader.cpp, line 848]
Comment 27 John J. Barton 2007-11-26 11:55:58 PST
It would be helpful to know which version of firebug was used?  1.05? If so, trying the test with 1.1 would be useful, http://fireclipse.xucia.com.
John
Comment 28 :Gijs Kruitbosch 2007-11-26 12:12:14 PST
I guess I'm the only one who is confused by timeless saying "I like the windows flavor better" and then posting a linux stack?

Also: crash . Timeless, let me know if that no longer works. Everyone else, ignore this paragraph. Sorry for spam.
Comment 29 timeless 2007-11-27 05:50:32 PST
#define windows not(mac)

:(. the mac stack traces seem to be victims of optimizers, the linux (..) stack trace i posted doesn't seem to suffer from optimizers and is therefore easier to follow.
Comment 30 [:Aleksej] 2007-12-17 23:40:03 PST
(In reply to comment #27)

On December 1st, I have updated Firebug from 1.05 to 1.1.0b10 from that site, and  the crash hasn’t happened to me since (yet).
Comment 31 Henrik Skupin (:whimboo) 2008-01-14 00:00:55 PST
I had the same silent crash today with Firfox2 and Firebug 1.05. First ten frames looks like:

0   libmozjs.dylib                 	0x00c8f16d js_LineNumberToPC + 29
1   libjsd.dylib                   	0x01a52889 NSGetModule + 14389
2   libjsd.dylib                   	0x01a52be2 NSGetModule + 15246
3   libxpcom_core.dylib            	0x00e5a8d9 XPTC_InvokeByIndex + 81
4   org.mozilla.firefox            	0x00370b23 XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) + 743
5   org.mozilla.firefox            	0x00362dc3 XPC_WN_CallMethod(JSContext*, JSObject*, unsigned, long*, long*) + 261
6   libmozjs.dylib                 	0x00c5a657 js_Invoke + 858
7   libmozjs.dylib                 	0x00c4cde1 js_Interpret + 4632
8   libmozjs.dylib                 	0x00c5adfe js_Invoke + 2817
9   org.mozilla.firefox            	0x005c1d72 nsXPCWrappedJSClass::CheckForException(XPCCallContext&, char const*, char const*) + 2454
10  org.mozilla.firefox            	0x005bef6b nsXPCWrappedJS::SystemIsBeingShutDown(JSRuntime*) + 483

Comment 32 Justin Dolske [:Dolske] 2008-03-02 00:26:42 PST
Based on comment #30, sounds like this problem does not occur with Firebug 1.1. Aleksej, I assume you've not seen this since then?

Talkback shows @js_GetScriptLineExtent as topcrash #244 (81 crashes in the last day), so this doesn't seem too common.
Comment 33 timeless 2008-03-02 01:28:17 PST
*** Bug 402513 has been marked as a duplicate of this bug. ***
Comment 34 [:Aleksej] 2008-03-02 02:08:16 PST
(In reply to comment #32)
Guess not; and I have switched to trunk (still without FireBug) sometime in January.
Comment 35 Akkana Peck 2008-03-25 21:04:51 PDT
Another metoo, this time in Linux: I've been seeing this maybe every other day lately, but this is the first time I've gotten a core from it so I could see where it was crashing. I do have Firebug installed, but it's 1.01, so I'll try upgrading it. I don't have any of the other extensions mentioned.
Comment 36 Rob Campbell [:rc] (:robcee) 2008-07-09 12:47:33 PDT
has this been fixed in Firefox 3.0.1, Firebug 1.1+? I've been running the latest 3.0.1 candidate with Firebug 1.2 all day without a crash.

Were there any particular steps to reproduce this when creating a new tab? Was firebug enabled, for instance?
Comment 37 MasterLeep 2008-07-14 14:50:57 PDT
I've had no similar crashes since switching to Firefox 3.0 and 1.2.0b4 in almost a month of use - at the least, a far lower rate than before.

Comment 38 Rob Campbell [:rc] (:robcee) 2009-10-28 13:17:47 PDT
if we're not seeing these bugs anymore can we mark this closed?

Note You need to log in before you can comment on or make changes to this bug.