Displaying a table with a BigDecimal column crashes the web UI

[jcferretti]

The following code crashes the web UI:

import deephaven.Types as dh
import jpy
jbigdecimal = jpy.get_type('java.math.BigDecimal')
t = dh.table_of([[jbigdecimal.valueOf(301, 2)], [jbigdecimal.valueOf(201,2)], [jbigdecimal.valueOf(101,2)]], [('decimal_value', dh.bigdecimal)])

Visually it looks like the two window captures below; the display stays for a few seconds as the first one, then chrome sees it crash as per the second one.

[niloc132]

Not sure specifically why you're getting a sigkill (linux killing the chrome process for oom?).

#513 is the issue to track the server implementing BigDecimal/BigInteger - the client has an attempt at reading it, but without the server speaking the same language, I didn't put any real effort into it.

However, if the server encounters a type that it can't send, it can turn it into a string and send that instead. We have support for that on the server, but in this case the client is incorrectly only reading the deephaven:type metadata and not checking the actual arrow type for the buffer. Right now this is unofficially part of #188, the rest of the js api's handling is "good enough".

Both of these should be resolve anyway, but handling either one will probably fix your issue. It would be worth trying to understand why chrome is getting its process killed though, to see if there is something else we can do to prevent it in general.

[jcferretti]

Not sure specifically why you're getting a sigkill (linux killing the chrome process for oom?).

Note the signal is SIGILL (Illegal Instruction), not SIGKILL (Kill signal). Which arguably makes it even weirder.
Thanks for the details and the reference issues, I'll take a peek at adding an InputStreamGenerator (per issue #513) for a decilmal128 equivalent type. There is an issue having to do with no perfect mapping for an arrow decimal type and DH's use of Java's BigDecimal: arrow decimal type is not one type but a family of decimal(precision,scale,bitwidth) types, where bitwidth is either 128 or 256, and precision is compatible with that; so some amount of guessing and hacking here is going to be required; what I am thinking here is essentially fitting a subset of the possible BigDecimals, which are likely the most common ones (eg, quantities representing amounts of currency), and a minimally user friendly way to blow up when you have actual data that can't be mapped, eg, a BigDecimal that has a huge precision that doesn't fit etc.

[niloc132]

Yikes you're right. And you were right, I should have waited until monday to look at this.

My brain replaced IG with somthing like K, while still leaving in the I and the G along the way. It would be nice to know what abuse of typedarrays is causing chrome to crash though, instead of a JS runtime error...

My best guess was that by misreading the flight schema I was allocating too much space and the JS runtime was crashing out rather than listen to me, but I'm not so sure now.