Unexpected behavior if fed several top copper files about tracespace HOT 4 OPEN

It doesn't seem necessary to have a timeout mechanism built into stackup. You can fairly trivially race two async functions using setTimeout or Promise.race.

Why stackup locks up on a particular would still be interesting to find out and try and fix. Maybe you can remove client confidential info from the Gerber and reduce it to just the error causing bits?

from tracespace.

Without any more information that "sometimes the session locks up", I agree with @kasbah on this one. Conceivable, there could be a bug somewhere in the library, but without files we can't really test. If you could reproduce with gerber-to-svg or pcb-stackup in isolation then we'd have something. Something that may be useful: do these same lockups happen in http://viewer.tracespace.io? If so, the console logs from there could be useful. If not, it may be an application issue rather than a library issue.

I'm gonna close this issue right now due to the lack of anything actionable. Happy to re-open if we dig something up as described above!

from tracespace.

In this particular case the svg that gets created by pcb-stackup is ~430MB large. Photoshop struggles to open it. I haven't been able to see how it looks.

This only happens with pcb-stackup. gerber-to-svg has no problems. I have also tested it on http://viewer.tracespace.io and although it does generate the individual layers the top and bottom view aren't displayed.

$ ls -lh *.svg
-rw-r--r--  1 user  staff   1.0K Mar 28 22:10 pcb-bottom.svg
-rw-r--r--  1 user  staff   430M Mar 28 22:10 pcb-top.svg

Reference code: https://gist.github.com/ju5t/f2b518eff1c0da01760eb6423a649c8e

==== JS stack trace =========================================

Security context: 0x342f83a25529 <JSObject>
    2: DoJoin(aka DoJoin) [native array.js:1] [bytecode=0x342fd61944a1 offset=212](this=0x342face022d1 <undefined>,o=0x342fc9197fc1 <JSArray[2]>,p=2,D=0x342face02371 <true>,z=0x342face02431 <String[0]: >,y=0x342face023e1 <false>)
    3: Join(aka Join) [native array.js:~119] [pc=0x1647eb6a8d5e](this=0x342face022d1 <undefined>,o=0x342fc9197fc1 <JSArray[2]>,p=2,z=0x342face02431 <String[0]: >,y=0x34...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [/usr/local/bin/node]
 2: node::OnFatalError(char const*, char const*) [/usr/local/bin/node]
 3: v8::Utils::ReportOOMFailure(char const*, bool) [/usr/local/bin/node]
 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/usr/local/bin/node]
 5: v8::internal::Factory::NewRawTwoByteString(int, v8::internal::PretenureFlag) [/usr/local/bin/node]
 6: v8::internal::Runtime_StringBuilderConcat(int, v8::internal::Object**, v8::internal::Isolate*) [/usr/local/bin/node]
 7: 0x1647eb523918
Abort trap: 6

I will e-mail you the files tomorrow.

from tracespace.

After examining the files, it looks like tracespace/whats-that-gerber#17 is rearing its head here (@ju5t see my email for a more detailed explanation). It then looks like if you feed bunch of files to pcb-stackup that wtg IDs as "top copper", pcb-stackup blows up.

I'm not sure what the "correct" behavior would be (bail out with a useful error?), but I'm comfortable enough calling this a bug. Very likely that it's coming in from pcb-stackup-core, but I haven't done any sort on analysis.

from tracespace.