Closed kloknibor closed 8 years ago
PS : not sure if this has to do anything do with #111 but might be ;)!
Can you attach the stl file that would load?
It doesn't really have anything to do with cleaning. It's the same stl loading bug that' I've had trouble recreating. For some reason I read an incorrect "HUGE" number of faces into Number_faces and explode the memory in one statement: Temp_Info = new byte[50*Number_faces]; // Each face has 50 bytes of data
I need your file to determine why that format does that sometimes.
Dup of #108. Still need that stl file though.
I'm not the owner of the file so I'll send it to you in private instead of posting it here for the world to see ;)
I was thinking about working on this, but the stl file that you sent me slices just fine. I've only tried this on Windows. I'll try to reproduce this on Raspberry Pi, but if I'm unsuccessful, I might have to have you give me the steps to reproduce it.
Tried on Raspberry Pi and couldn't reproduce. Do you have further steps to reproduce this?
This bug kindof prompted me to do some memory profiling today and I found that I had a pretty nasty memory leak. I used a 50mb stl model for my profiling.
Notice the second time I attempted to print that model, the jvm didn't even collect the first print job.
After I fixed the bug, it dropped well below where the STL file was originally loaded. So we are looking pretty clean now.
Fixed in Dev-006
Hi,
I started the same model quite a few times for testing purposes, lowered my exposure time to 10S and used the following code for Z lift :
G1 Z6.0 F100.0 ; 12200
G1 Z-5.9 F100.0
; 14200
and set it back later to
G1 Z6.0 F30.0 ; 12200
G1 Z-5.9 F30.0
; 14200
The file which worked previously now returns an heap space error... Also an new uploaded file creates an heap space error! I suspect that something is not cleaned well... Here are the logs :
LogBundle (3).zip.pdf