tpb has joined #symbiflow
mzyn22 has joined #symbiflow
mzyn22 has left #symbiflow [#symbiflow]
citypw has joined #symbiflow
Bertl_zZ is now known as Bertl
OmniMancer has joined #symbiflow
_whitelogger has joined #symbiflow
OmniMancer has quit [Read error: Connection reset by peer]
Bertl is now known as Bertl_oO
freemint has quit [Ping timeout: 245 seconds]
freemint has joined #symbiflow
craigo has quit [Ping timeout: 265 seconds]
freemint has quit [Remote host closed the connection]
freeemint has joined #symbiflow
galv[m] has quit [Remote host closed the connection]
lromor[m] has quit [Remote host closed the connection]
xobs has quit [Read error: Connection reset by peer]
synaption[m] has quit [Read error: Connection reset by peer]
mrhat2010[m] has quit [Read error: Connection reset by peer]
hzeller[m] has quit [Read error: Connection reset by peer]
zeigren has quit [Read error: Connection reset by peer]
nrossi has quit [Read error: Connection reset by peer]
alexhw[m] has quit [Remote host closed the connection]
alexhw has quit [Remote host closed the connection]
alexhw has joined #symbiflow
alexhw has quit [Remote host closed the connection]
citypw has quit [Ping timeout: 240 seconds]
Bertl_oO is now known as Bertl
nrossi has joined #symbiflow
alexhw[m] has joined #symbiflow
hzeller[m] has joined #symbiflow
xobs has joined #symbiflow
synaption[m] has joined #symbiflow
zeigren has joined #symbiflow
galv[m] has joined #symbiflow
lromor[m] has joined #symbiflow
mrhat2010[m] has joined #symbiflow
freeemint has quit [Remote host closed the connection]
freeemint has joined #symbiflow
<tpb> Title: GitHub - SymbiFlow/vtr-verilog-to-routing: SymbiFlow WIP changes for Verilog to Routing -- Open Source CAD Flow for FPGA Research (at github.com)
<litghost> mkurc: We cannot predict when Kevin or another VTR dev will be able to merge that PR
freeemint has quit [Ping timeout: 246 seconds]
<sf-slack> <mkurc> @litghost Sure, I'll address your review and then create the wip/ branch.
freeemint has joined #symbiflow
freeemint has quit [Ping timeout: 245 seconds]
freeemint has joined #symbiflow
freeemint has quit [Remote host closed the connection]
freeemint has joined #symbiflow
adjtm_ has joined #symbiflow
adjtm has quit [Ping timeout: 276 seconds]
Bertl is now known as Bertl_zZ
craigo has joined #symbiflow
freeemint has quit [Ping timeout: 245 seconds]
<hackerfoo> litghost: I haven't had time to reproduce the lxml crash yet, but I found this: https://bugs.launchpad.net/lxml/+bug/1570388
<tpb> Title: Bug #1570388 “Serialisation error when writing a large file (> 2...” : Bugs : lxml (at bugs.launchpad.net)
<litghost> If that is the issue, it was reported 3 years ago, and got absolutely no updates
<litghost> So :(
<litghost> However it does seem like it has a good chance of matching our issue
<litghost> I'm trying their replication now to see if it fails in the same way
<litghost> I'm working on getting usan/asan/etc to run against libxml2/libxslt and see what (if anything) crops up
<tpb> Title: Bug 796192 libxml2, xml file reader issue when file size is greater than 2GB (at bugzilla.gnome.org)
<litghost> hackerfoo: Yes, which makes finding the bug more "exciting"
<litghost> hackerfoo: The bug could exist in lxml, libxml2, or be an exciting combination !!!
<hackerfoo> It could still be in our code, too.
<litghost> Nope! Because https://bugs.launchpad.net/lxml/+bug/1570388 is exactly our bug
<tpb> Title: Bug #1570388 “Serialisation error when writing a large file (> 2...” : Bugs : lxml (at bugs.launchpad.net)
<litghost> Like exact same symptom and everything
<litghost> Now it is possible that they (openpyxl) have the same bug we do, but that feels unlikely
<hackerfoo> Well, now we have code to reproduce the bug.
<litghost> Kind of, it's still intermixed with openpyxl, so it is no better per say than what we have
<litghost> A straight forward large loop didn't replicate
freeemint has joined #symbiflow
<duck2> did we upgrade to a >2.5gb xml file? :D
<litghost> ~3.8 GB :D
freeemint has quit [Ping timeout: 250 seconds]
<litghost> I found the libxml2 bug, and it super stupid
<hackerfoo> What was it?
<litghost> int written ... written += bytes_write_last_call ... if (written < 0) error
<litghost> e.g. what we expected
<litghost> libxml2 is totally misusing int (versus size_t/ssize_t)
<hackerfoo> I wonder if Clang or GCC has a warning for that (casting size_t/ssize_t to int.)
<litghost> hackerfoo: It does not, but "-fsanitize=undefined" with clang produced:
<litghost> xmlIO.c:3416:19: runtime error: signed integer overflow: 2147481777 + 4000 cannot be represented in type 'int'
<litghost> e.g. overflowing written
<hackerfoo> So can we use the whole 50T now?
<duck2> oooh
<litghost> I'm working on a patch, but I believe there was never actually a problem in the output, except that the written counter overflowed
<litghost> And this is why size_t and ssize_t should always be used over int
<duck2> so it's why it occurs when the file is >2gb
<litghost> We suspected it was a 32-bit overflow issue, but the question was where
freeemint has joined #symbiflow
alainmarcel has joined #symbiflow
tpb has quit [Remote host closed the connection]