mozilla :: #jsapi

20 Mar 2017
00:23shumrgiggles: pun
00:23mrgigglesshu: I tried working in an orange juice factory, but I got canned because I couldn't concentrate.
09:46ptomato-MI'm moving GJS on from esr38 to esr45 now and I'm having some trouble running even a minimum embedded program:
09:46ptomato-Msegfault in JS_NewContext
09:46firebotBug 1348739 UNCONFIRMED, Minimal embedding crash in JS_NewContext
09:46ptomato-Many suggestions?
09:46arai-awayI think I saw the backtrace before
09:47arai-awayperhaps something related to linking
09:49ptomato-Marai-away: could well be that I'm not linking correctly
09:49ptomato-Mlet me find the command line
09:50jandemptomato-M: bug 1176787
09:50firebot NEW, MOZ_GLUE_IN_PROGRAM breaks static linking of SM into executables
09:52ptomato-Mjandem: thanks. let me take a look at that patch
09:52ptomato-MI'm not linking statically though
09:54ptomato-Mhere's my command line: g++ -std=c++11 -O0 -g -include $HOME/install/include/mozjs-45/js/RequiredDefines.h -I$HOME/install/include/mozjs-45 -DDEBUG test45.cpp -o test45 -L$HOME/install/lib -lmozjs-45
10:11ptomato-Mjandem: arai-away: yep, that patch did it
10:11arai-awaynice :)
10:11ptomato-Mbut it seems like it's too configuration-dependent to land in that form?
10:12jandemwe really need to get that fixed :/
10:12ptomato-Mwith GJS I'll have to support whatever configurations the downstream distros build spidermonkey with :-/
10:12ptomato-MI personally use --enable-posix-nspr-emulation but that breaks --enable-ctypes (which I don't use)
10:13ptomato-MI know fedora builds --enable-system-nspr and --enable-ctypes
12:56Yoricstandups: Bug 1347711 - Refactor error reporting out of TokenStream - Shaving the yak
12:56standupsOk, submitted #43918 for
12:56firebot NEW, Refactor error reporting out of TokenStream
15:56bbouvier!seen anba
15:56firebotanba was last seen 9 days and 18 hours ago, saying 'Waldo: Oh btw, you're going to "like" bug 1345115. It's always fun time when parameters are named "bufferMaybeDetached", "bufferMaybeUnwrapped", and even "unwrappedBufferMaybeDetached"! :-p' in #jsapi.
16:13Yoricstandups: Bug 1348883 - Refine histogram DOM_SCRIPT_SRC_ENCODING - followup, as requested
16:13standupsOk, submitted #43933 for
16:13firebot NEW, Refine histogram DOM_SCRIPT_SRC_ENCODING
16:31mrgigglesthe mozilla-inbound tree is now closed (test failures from bug 1346810)
16:31firebot ASSIGNED, Crash [@ js::jit::MBasicBlock::add] with OOM and asm.js
17:20Yoricshu: I'll try to cut my patch in smaller patches.
17:28ptomato-Mas of esr45, does JS_DefineProperty() now enter an object's resolve callback where in esr38 it didn't?
17:32joncosfink: thanks for fixing bug 1346874
17:32firebot FIXED, Skip slower gray marking checks on Android
17:40shuYoric: i haven't had a chance to look yet
17:40shuYoric: but i don't mind big patches actually, easier for me to see the big picture
17:40shui know other folks like multiple parts though
17:46nbpMy point of view, is that multiple parts is the best way to sneak in changes, and big patches have exponential review time or more (if done properly)
17:46mrgigglesthe mozilla-inbound tree is now open
18:00djvjso, profiling js with vtune, noticing that CPI rate for baseline code is high (from 2.0 to 3.5)
18:01tcampbelldjvj: is branch prediction also bad?
18:15djvjtcampbell: not sure.. that column is gray
18:36Yoricshu: Ok, in that case, I'll keep the big patch.
19:17decoderi just hit 4 assertions at once in the js engine
19:17decoderin one run
19:17decoderdid I win anything?
19:19tcampbelljob security, I guess?
19:23tcampbellI mean, that's a pretty good prize
19:29decoderheh. just that all those asserts are fatal asserts
19:29decoderand we shouldnt be hitting two at once
19:29decodernot to speak of 4 at once
21:49evilpiejandem: on google docs we log this exact CacheIR analyzer entry 50 times, I wonder how this could happen?
21:53jandemevilpie: might be the thing I saw on octane typescript, I'll land these patches tomorrow
21:54evilpiewe are not actually reattaching that stub though, right?
21:55evilpiethis also happening for about 100 times
21:55jandemwe should attach it only once
21:55evilpiecongratulations on getting this landed
21:56jandemI wouldn't trust the setprop results until I land the followup changes
21:56jandemyeah finally, hopefully the last big IC change for now
21:56evilpieok I will give it a try tomorrow
21:57jandemgood to know we hit this on Google docs
21:57jandemthese stubs I mean
21:58evilpieWe also get repeated GetProp stubs
21:59evilpieit's the third most common GetProp and SetProp stub
22:01jandemevilpie: can you pastebin a getprop one? That stub should handle most cases I think
22:01evilpie about 95
22:12tcampbelljandem: can I r? you on this INITELEM_INC bug? I'm doing some testing but I seem to have it working
22:13tcampbellthese array initializer holes turned into a nuisance for me
22:16ron_hi guys, newbie here that needs a bit of help. I make an XHR and want to parse the JSON response, the nsIXMLHTTPRequest::GetResponse seems like it would be able to do that for me according to this
22:16jandemtcampbell: sure, i can look at it tomorrow. Landing the VM call is also fine btw
22:16ron_I managed to find it being used here -
22:16ron_Is this how I should go about fetching the JSContext and using GetResponse? Thanks in advance!
22:17tcampbelljandem: yeah, I've avoided the VMCall version all together and went the IC route you suggested. It is cleaner, it just triggered a few issues that took some time to understand.
22:18jandemtcampbell: nice
22:18tcampbellthere were many failed attempts =\
22:19jandemron_: #content is probably a better channel for this, /cc bz
22:19ron_ok thanks!
22:20mrgigglesthe mozilla-inbound tree is now closed (bustage)
22:28jandemWaldo: finally picked up Name of the Wind again, it's getting interesting now that the storytelling started but still lots of questions :)
22:28mrgigglesthe mozilla-inbound tree is now open
22:29jandemabout 20% in or so
22:48sfinkjandem: I am debugging a case where an object (well, a CCW) is getting marked because it's stored in an IC stub field. Are you around for a few questions?
22:49jandemsfink: a bit.. leaving in a few minutes
22:49sfinkok, cool
22:50sfinkso I thought this wouldn't happen because I'm doing a GC that discards jit code
22:50sfinkand this is from schedulePreciseGC, so there's nothing on the stack
22:50sfinkbut I notice that at least in one case, script->baselineScript()->active() is returning true
22:50sfinkis that expected?
22:51sfink(I haven't made it to the script in question yet, so I don't know for sure this is what's going wrong)
22:51jandemsfink: that means it is on the stack.. could it be a nested event loop or something?
22:52sfinkno, the stack shows main -> ... ProcessNextEvent -> PreciseGCRunnable::Run -> GC
22:52sfinkthe main thread, at least
22:54jandemsfink: could check what happens in MarkActiveBaselineScripts
22:54sfinkjandem: oh, wait. Never mind. active() isn't returning true, it's just gdb doing weird stuff and claiming that it's executing a line of code inside of an if (active) { ... }
22:55jandemsfink: ah
22:55sfinkok, the active thing is a red herring. It's still marking the stub field, but probably not because it thinks it's active
22:56jandemmaybe a post barrier?
22:56jandemor we preserve jit code for some reason
22:56tcampbell(Is there a quick way to make an UnboxedArrayObject?)
22:57sfinkno, I added something that forces it to discard jit code here, and it seems to work at least insofar as all the zones are returning false for preserving jit code
22:57sfinkincluding the zone of interest
22:57jandemtcampbell: you need --unboxed-arrays for that, but it doesn't pass jit tests atm so it's pretty annoying. I wouldn't worry too much about it
22:58jandemsfink: hm no idea then
22:58tcampbelljandem: good to know. I mostly just wanted to test some index overflow behaviour with a 2^31 element array ...
22:58sfinkjandem: yeah, thanks, I'll keep debugging. Just wanted to check on that active thing.
22:59jandemtcampbell: see UnboxedArrayObject::MaximumCapacity fwiw
22:59jandemsfink: ok good luck
23:01tcampbellgood point. I guess I won't stress about this then
21 Mar 2017
No messages
Last message: 153 days and 15 hours ago