Time |
Nick |
Message |
01:14 |
|
sandbergja joined #evergreen |
01:58 |
|
sandbergja joined #evergreen |
06:01 |
pinesol |
News from qatests: Failed Installing Evergreen pre-requisites - Expected 1 errors but encountered 3. <http://testing.evergreen-ils.org/~live/test.26.html#2019-12-09T06:00:09,402632214-0500 -0> |
07:03 |
|
agoben joined #evergreen |
07:50 |
|
collum joined #evergreen |
07:59 |
|
mantis1 joined #evergreen |
07:59 |
|
alynn26 joined #evergreen |
08:34 |
csharp |
well, I just hit the same issue as dbs with a whitescreen on FF 71.0 (dbs described it here: http://irc.evergreen-ils.org/evergreen/2019-12-06#i_429453 ) |
08:35 |
csharp |
same error in the console: Error loading shared worker |
08:35 |
csharp |
error { target: SharedWorker, isTrusted: true, message: "DataCloneError: The object could not be cloned.", filename: "https://gapines.org/js/ui/default/staff/offline-db-worker.js", lineno: 344, colno: 0, srcElement: SharedWorker, currentTarget: SharedWorker, eventPhase: 2, bubbles: false, … } |
08:35 |
csharp |
core.bundle.js:1:62466 |
08:35 |
csharp |
onerror https://gapines.org/js/ui/default/staff/build/js/core.bundle.js:1 |
08:37 |
csharp |
line 344 of offline-db-worker.js is "port.postMessage(data);" |
08:38 |
csharp |
looks like the same issue as this: https://stackoverflow.com/questions/27558398/datacloneerror-the-object-could-not-be-cloned-in-firefox-34 |
08:39 |
csharp |
same error after clearing cache & cookies |
08:40 |
csharp |
Chrome 78.0.3904.108 is fine |
08:42 |
|
dbwells joined #evergreen |
08:42 |
|
dbwells joined #evergreen |
08:46 |
|
mmorgan joined #evergreen |
08:53 |
csharp |
I had a colleague upgrade FF to 71.0 on Windows (I'm on F31) and the problem didn't happen there, so fingers crossed that this doesn't have a huge impact |
08:53 |
|
Dyrcona joined #evergreen |
08:53 |
csharp |
most of our libs were trained into using Chrome (for Hatch), so good that we have a viable workaround |
08:57 |
Dyrcona |
csharp | dbs I suspected it was Firefox version-specific. |
08:59 |
csharp |
if dbs is also on F31 and we're not seeing it elsewhere, maybe something's borked only on that platform |
09:00 |
csharp |
I didn't have any issues on whatever FF Ubuntu 19.10 is running on my home desktop on Friday |
09:00 |
Dyrcona |
I'm using Ubuntu 19.10, and it has FF70. |
09:00 |
csharp |
ah |
09:01 |
Dyrcona |
70.0.1 (64-bit) |
09:02 |
Dyrcona |
We also recommend Chrome here at CW MARS. |
09:05 |
* csharp |
hates recommending a proprietary browser to run his beloved F/LOSS, but them's the breaks, I guess |
09:05 |
Dyrcona |
Well, Chromium also works. :) |
09:05 |
csharp |
yeah :-) |
09:06 |
|
rfrasur joined #evergreen |
09:29 |
dbs |
csharp: I am indeed on F31 |
09:29 |
dbs |
Now trying to remember if I ran into this while I was testing on Windows, however... |
09:30 |
* dbs |
curses dbs_windows for not having reported back on that |
09:39 |
csharp |
heh |
09:39 |
JBoyer |
Quick data point: I tried FF 71 on macOS and did not run into the issue. |
09:39 |
csharp |
JBoyer: thanks for that confirmation |
09:40 |
* csharp |
went to start his Windows 10 VM only to realize the station he's on doesn't have one installed yet :-/ |
09:40 |
JBoyer |
So it looks Linux specific at the moment, which, while not great, really is the ideal situation if there *has* to be a problem. |
09:40 |
csharp |
JBoyer: agreed |
09:41 |
* JBoyer |
remembers he's standing right next to a Windows laptop, will test right now. |
09:42 |
csharp |
and Google Music Desktop Player also stopped working on Linux for me, so all the software is breaking |
09:42 |
csharp |
@who broke the softwares |
09:42 |
pinesol |
felicia broke the softwares. |
09:42 |
* mmorgan |
is having flashbacks to those mac dude vs. pc guy commercials |
09:45 |
JBoyer |
UGH. That old smushbox keyboard is like typing on bugs. |
09:46 |
JBoyer |
Anyway, FF 71 on Windows was fine. |
09:46 |
JBoyer |
I was testing on master, to double check, what server versions have you seen issues on? |
09:46 |
remingtron |
FF 71 on Windows also works fine for me (EG 3.3.1) |
09:51 |
csharp |
JBoyer++ remingtron++ # thanks for confirming |
10:00 |
|
mmorgan1 joined #evergreen |
10:00 |
|
sandbergja joined #evergreen |
10:03 |
Dyrcona |
Another data point: Chromium isn't printing correctly for me today on my Linux laptop, but LibreOffice is. Chromium just spits out a single blank page on the office printer. |
10:03 |
berick |
re: FF data clone, if we can isolate the data it's complaining about, it should be fixable. |
10:08 |
Dyrcona |
berick: I thought of that earlier, but wonder if this is something that will get fixed by FF. |
10:08 |
Dyrcona |
...eventually. |
10:09 |
berick |
guess it depends on whether it's a problem w/ our code |
10:25 |
|
devted joined #evergreen |
10:32 |
csharp |
berick: that would just require a console.log statement somewhere, yes? |
10:39 |
|
mmorgan joined #evergreen |
10:42 |
berick |
csharp: yep |
10:42 |
dbs |
remingtron / JBoyer: can you try flipping around between various interfaces (admin workstations, printer settings, cataloguing, etc)? |
10:42 |
dbs |
I don't think it manifested immediately for me; it happened after using it for a while |
10:42 |
berick |
csharp: in lovefield.js -- in the service.relayRequest() function. log the 'args' |
10:43 |
JBoyer |
I had gone to two or three screens since I wasn't sure where it was happening, but I'll try to get a little better coverage. |
10:44 |
berick |
if the data is problematic in the other direction, then edit offline-db-worker.js, and log the 'data' in replySuccess() and replyError(). |
10:44 |
berick |
csharp: ^- |
10:59 |
csharp |
berick: it's coming out in the console as "[object Object]" - looking into that |
10:59 |
|
Christineb joined #evergreen |
11:00 |
berick |
csharp: log the value without any strings.. console.log(args) |
11:01 |
csharp |
oh, I see |
11:01 |
berick |
in chrome, anway, that will give you a navigable object in the console |
11:04 |
csharp |
Object { schema: "cache", table: "Setting", action: "insertOrReplace", rows: (5) […], id: 3, status: "ERR", error: "[object Event]" } |
11:05 |
csharp |
it has a large expandable tree - not sure what's useful yet |
11:06 |
berick |
csharp: ok, this is helpful... |
11:06 |
csharp |
schschema: "cache" status: "ERR" table: "Setting" |
11:06 |
berick |
csharp: mind commenting out this line in offline-db-worker.js ? |
11:06 |
berick |
data.error = err; |
11:06 |
berick |
in replyError() |
11:07 |
csharp |
done |
11:08 |
csharp |
now it loads, btw |
11:09 |
csharp |
confirmed - with that line commented out, it loads the splash |
11:09 |
csharp |
error is still in the console, though |
11:09 |
berick |
awesome |
11:09 |
berick |
thanks csharp |
11:10 |
berick |
so we should bug and patch that |
11:10 |
berick |
and instead of returning the error just log it on the worker side |
11:12 |
berick |
of course, we also need to diagnose the core problem, i.e. why it's throwing the error. may need more logging for that. |
11:13 |
berick |
specically the 'err' value |
11:16 |
csharp |
berick: https://bugs.launchpad.net/evergreen/+bug/1855737 |
11:16 |
pinesol |
Launchpad bug 1855737 in Evergreen "Web Client Whitescreen on Firefox 71.0 on Linux hosts" [Undecided,Confirmed] |
11:17 |
berick |
csharp++ |
11:17 |
csharp |
berick++ |
11:21 |
* berick |
comments https://bugs.launchpad.net/evergreen/+bug/1855737/comments/1 |
11:21 |
pinesol |
Launchpad bug 1855737 in Evergreen "Web Client Whitescreen on Firefox 71.0 on Linux hosts" [Undecided,Confirmed] |
11:41 |
|
sandbergja joined #evergreen |
11:46 |
berick |
csharp: are you seeing another error in the console that starts with 'shared worker replying with error' ? |
11:46 |
berick |
should happen just before the dataclone error was happening |
11:46 |
dbs |
csharp++ |
11:46 |
dbs |
berick++ |
11:48 |
Dyrcona |
berick++ csharp++ dbs++ |
12:01 |
csharp |
berick: yes, I'm also seeing that |
12:01 |
csharp |
shared worker replying with error [object Event] |
12:02 |
berick |
oh, lame |
12:03 |
berick |
i wonder if it would show something useulf if it was just console.error(err) |
12:04 |
berick |
FF might stringify log values when separated by commas unlike chrome |
12:07 |
csharp |
where's the file I should change for that? |
12:07 |
berick |
csharp: offline-db-worker.js about 2 lines up |
12:08 |
berick |
in replyError() |
12:10 |
csharp |
berick: not sure it's much better, but https://pastebin.com/Mn73DEqC |
12:10 |
berick |
dang |
12:11 |
Dyrcona |
Heh. How quaint: https://pastebin.com/auAZache Looks we have some competition. :) |
12:11 |
berick |
csharp: thanks. not sure how much you want to dig right now, but next up may be adding logging to insertOrReplace |
12:12 |
csharp |
{"isTrusted":true} |
12:12 |
csharp |
that's what happens when I wrap err in JSON.stringify() |
12:13 |
csharp |
not sure it helps |
12:13 |
berick |
huh |
12:16 |
csharp |
if you have more I can help with, just let me know - I'm multi-tasking, but I can definitely keep going |
12:16 |
dbs |
this is the one security fix related to workers I found in the 71.0 release notes: https://www.mozilla.org/en-US/security/advisories/mfsa2019-36/#CVE-2019-17008 (unfortunately no details released yet) |
12:16 |
pinesol |
A vulnerability in field-programmable gate array (FPGA) ingress buffer management for the Cisco Firepower 9000 Series with the Cisco Firepower 2-port 100G double-width network module (PID: FPR9K-DNM-2X100G) could allow an unauthenticated, adjacent attacker to cause a denial of service (DoS) condition. Manual intervention may be required before a device will resume normal operat... (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1700) |
12:17 |
dbs |
close but no cigar, pinesol, you need the '8' at the end :) |
12:17 |
csharp |
heh |
12:17 |
berick |
csharp: logging in insertOrReplace would be my next step. logging, like, all of it. |
12:23 |
csharp |
berick: https://pastebin.com/Ej8HPyEP - I logged "info" and "rows" |
12:23 |
|
khuckins joined #evergreen |
12:26 |
|
gerlevi joined #evergreen |
12:27 |
berick |
csharp: thanks, looking |
12:28 |
berick |
csharp: did you log rows before or after the object.map(..) line? |
12:28 |
csharp |
after |
12:28 |
berick |
k |
12:28 |
csharp |
berick: https://pastebin.com/wJmEFk0F |
12:38 |
|
collum joined #evergreen |
12:53 |
berick |
sigh, poking 71 on linux and can't reproduce after many navigations. the org setting values I'm storing even match the 'null's from csharp's log |
12:53 |
csharp |
ugh |
12:53 |
csharp |
is that Ubuntu? |
12:54 |
berick |
yeah, 16.04, runnng FF directly from the tarball |
12:54 |
csharp |
ok -hmm |
12:54 |
Dyrcona |
@blame Fedora |
12:54 |
pinesol |
Dyrcona: Fedora typed Google into Google; broke the Internet. |
12:54 |
csharp |
I wonder if the Fedora packagers do something |
12:54 |
csharp |
yeah |
12:55 |
dbs |
SELinux? |
12:55 |
dbs |
Seems like a longshot, but... |
12:55 |
Dyrcona |
I doubt it's SELinux. |
12:56 |
Dyrcona |
Could be, though, but yeah, it's a long shot. |
12:56 |
csharp |
that used to be a huge factor when I first started using Fedora, but in the past 4 or so years, I've only occasionally hit issues with it |
12:56 |
csharp |
worth ruling out, for sure |
12:56 |
* dbs |
runs sudo setenforce 0 just for fun |
12:56 |
Dyrcona |
I suppose if it stops lovefiled from creating files... |
12:58 |
csharp |
nothing in the audit.log with "deni" (case insensitive) |
12:58 |
* csharp |
remembers that dbs's alternate nick is denials :-) |
12:59 |
Dyrcona |
:) |
12:59 |
dbs |
mmm... https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Testing_Mozilla_binaries |
13:00 |
dbs |
could rule out packaging hijinks that way |
13:00 |
dbs |
FWIW I also saw no difference with SELinux disabled |
13:00 |
* dbs |
will commence downloading |
13:05 |
dbs |
hmm. initial testing suggests that the vanilla mozilla version of Firefox 71.0 is not affected |
13:06 |
dbs |
csharp++ # avoiding log alerts for me - so kind |
13:06 |
csharp |
dbs: ha! |
13:07 |
csharp |
dbs: very interesting - so this really must be a Fedora thing |
13:07 |
csharp |
@who lives in a Fedora bubble? |
13:07 |
pinesol |
rashma lives in a Fedora bubble. |
13:11 |
dbs |
however I also created a brand new firefox profile for this, so... |
13:13 |
dbs |
Hah! And using the same new profile as was created in vanilla FF 71.0 in Fedora's version of FF 71.0 triggers the bug |
13:13 |
dbs |
I think that's as smoking gun as we can get |
13:14 |
dbs |
Then the question is: how the heck do we build a minimal reproducible test case for the Fedorans? |
13:14 |
csharp |
hmmm |
13:14 |
csharp |
dbs++ # detective work |
13:20 |
JBoyer |
dbs++ |
13:36 |
dbs |
the third file patched in https://src.fedoraproject.org/rpms/firefox/c/0f0618f13f764427bd55921e8a3cb7469984391b?branch=master looks like it might be relevant; not yet in stable F31 |
13:39 |
dbs |
but who knows, that was supposed to be to avoid crashes on startup (https://bugzilla.mozilla.org/show_bug.cgi?id=1601707) - *sigh* so many possibilities from different compile flags, different versions of deps :/ |
13:39 |
pinesol |
dbs: Error: Could not parse XML returned by Mozilla: Connection reset by peer. (http://bugzilla.mozilla.org/xml.cgi?id=1601707) |
13:43 |
csharp |
yikes |
13:44 |
csharp |
well, to expand JBoyer's observation earlier about OS impact, this is ideal |
13:45 |
csharp |
and I'm utterly unsure whether we should consider this an EG bug at all |
13:45 |
csharp |
unless there's some best practice not being followed that this is revealing (possibly like the Safari expire date thing), probably not |
13:46 |
dbs |
Right, I don't think it's an EG thing either |
13:46 |
dbs |
Or at least, EG should be considered innocent until proven guilty :) |
13:47 |
Dyrcona |
Nope. It's a combination of a "compiler bug" and some stupid c++ code that triggers it. |
13:47 |
csharp |
berick: thanks for your help in troubleshooting - sorry to have you spend cycles on something that's mostly inconsequential :-/ |
13:47 |
Dyrcona |
If I'm reading the bugs correctly. |
13:49 |
csharp |
in other news, we got Disney+ this weekend and are all caught up on the Mandalorian (great show, despite my anti-endless-star-wars stance) and I'm about halfway through The Black Hole, which I'm pretty sure I haven't seen since my 20s and was one of my favorites as a child |
13:55 |
Dyrcona |
I guess the Mozilla devs didn't get the memo that C++ is now supposed to be written like a scripting language. :) |
13:58 |
* Dyrcona |
hasn't seen The Black Hole in ages. I remember it as being good Sci-Fi. |
13:58 |
JBoyer |
The thing about ambiguity and undefined behavior is that calling abort() is a behavior that does a great job of collapsing ambiguity like a quantum physics wave function. |
13:59 |
Dyrcona |
JBoyer++ |
14:01 |
Dyrcona |
BTW, Bmagic, if you're thinking of programming with threads, I'd also recommend C++17. |
15:05 |
Bmagic |
Dyrcona++ |
15:13 |
eby |
jeff: you have haproxy in front of incipit by chance |
15:13 |
jeff |
negative. nginx in some/all cases, but not haproxy. |
15:25 |
|
mantis1 left #evergreen |
15:27 |
|
dbwells joined #evergreen |
15:29 |
|
dbwells_ joined #evergreen |
15:38 |
dbs |
oh huh "FF 71.0 breaks many extensions because it can't write to local storage - but upstream works": https://bugzilla.redhat.com/show_bug.cgi?id=1779570 |
15:40 |
dbs |
(and that points to the previously linked mozilla bug) |
15:41 |
dbs |
So yeah, definitely seems to be specific to Fedora (although Debian Unstable is apparently reporting similar issues with FF 71.0) |
15:42 |
Dyrcona |
Looks like a GCC bug ultimately. |
15:42 |
Dyrcona |
Clang builds apparently work. |
15:43 |
dbs |
This also explains why my BitWarden add-on stopped syncing |
15:44 |
Dyrcona |
Reading bug comments is....interesting. :) |
15:45 |
dbs |
always :) |
15:45 |
* dbs |
enjoyed experimenting with compiling Evergreen with clang years back, but the performance bottleneck isn't in the C code anyway |
15:46 |
Dyrcona |
:) |
16:39 |
|
yboston joined #evergreen |
17:07 |
|
mmorgan left #evergreen |
18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:22 |
|
dbwells joined #evergreen |
18:51 |
|
rfrasur joined #evergreen |
21:14 |
|
sandbergja joined #evergreen |
22:07 |
|
sandbergja joined #evergreen |