2.1.0 crash during print on macos 14.4

[keefo]

I have a consistent crash repro during print. My printer is ender 3v2 with BIGTREETECH SKR MINI E3 V3.0 board.

Here is the gcode I use, when I print this around 1h 02m the app crash and print stopped. I have tried 2 times, crash at the same step.

I am able to finish print of many other models, it is just this model which trigger the crash. please see the gcode file in attachment.

This is the crash call stack:

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000

Termination Reason:    Namespace SIGNAL, Code 6 Abort trap: 6
Terminating Process:   Pronterface [17715]

Application Specific Signatures:
Graphics hardware encountered an error and was reset: 0x00000001

Thread 0 Crashed:
0   libsystem_kernel.dylib              0x7ff81331314a 0x7ff81330b000 + 33098
1   libsystem_c.dylib                   0x7ff813271a39 0x7ff8131f2000 + 522809
2   libGPUSupportMercury.dylib          0x7ff92671752f gpusGenerateCrashLog + 157
3   AMDRadeonX5000GLDriver                 0x12a829928 gpusKillClientExt + 9
4   libGPUSupportMercury.dylib          0x7ff926718a46 gpusSubmitDataBuffers + 497
5   AMDRadeonX5000GLDriver                 0x12a866362 glrATI_Hwl_SubmitPacketsWithToken + 122
6   AMDRadeonX5000GLDriver                 0x12a86923e gldPresentFramebufferData + 83
7   GLEngine                            0x7ffa2f86b3c9 glSwap_Exec + 105
8   OpenGL                              0x7ffa2f6438cb 0x7ffa2f636000 + 55499
9   AppKit                              0x7ff816db1ac5 0x7ff816a50000 + 3545797
10  libwx_osx_cocoau_gl-3.2.0.2.1.dylib        0x1273d8ad2 wxGLCanvas::SwapBuffers() + 50
11  _glcanvas.cpython-310-darwin.so        0x12740cb55 meth_wxGLCanvas_SwapBuffers(_object*, _object*) + 101
12  libpython3.10.dylib                    0x10e528a4a cfunction_call + 90
13  libpython3.10.dylib                    0x10e4c0704 _PyObject_MakeTpCall + 132
14  libpython3.10.dylib                    0x10e5fb563 call_function + 371
15  libpython3.10.dylib                    0x10e5f2bef _PyEval_EvalFrameDefault + 27983
16  libpython3.10.dylib                    0x10e5ea7af _PyEval_Vector + 383
17  libpython3.10.dylib                    0x10e5fb49f call_function + 175
18  libpython3.10.dylib                    0x10e5f1509 _PyEval_EvalFrameDefault + 22121
19  libpython3.10.dylib                    0x10e5ea7af _PyEval_Vector + 383
20  libpython3.10.dylib                    0x10e4c497d method_vectorcall + 365
21  _core.cpython-310-darwin.so            0x1105a8e0e wxPyCallback::EventThunker(wxEvent&) + 222
22  libwx_baseu-3.2.0.2.1.dylib            0x10fad9dad wxEvtHandler::SearchDynamicEventTable(wxEvent&) + 301
23  libwx_baseu-3.2.0.2.1.dylib            0x10fad9acb wxEvtHandler::ProcessEventLocally(wxEvent&) + 59
24  libwx_baseu-3.2.0.2.1.dylib            0x10fad9980 wxEvtHandler::ProcessEvent(wxEvent&) + 96
25  _glcanvas.cpython-310-darwin.so        0x127407b09 sipwxGLCanvas::ProcessEvent(wxEvent&) + 105
26  libwx_baseu-3.2.0.2.1.dylib            0x10fada09c wxEvtHandler::SafelyProcessEvent(wxEvent&) + 12
27  libwx_osx_cocoau_core-3.2.0.2.1.dylib          0x1112c0506 wxWindow::MacDoRedraw(long) + 678
28  libwx_osx_cocoau_core-3.2.0.2.1.dylib          0x11138a036 wxWidgetCocoaImpl::drawRect(void*, NSView*, void*) + 742
29  libwx_osx_cocoau_core-3.2.0.2.1.dylib          0x111386fa6 wxOSX_drawRect(NSView*, objc_selector*, CGRect) + 86
30  AppKit                              0x7ff8172f25d1 0x7ff816a50000 + 9053649
31  QuartzCore                          0x7ff81ba24f15 0x7ff81ba03000 + 139029
32  QuartzCore                          0x7ff81bbbcd88 0x7ff81ba03000 + 1809800
33  QuartzCore                          0x7ff81ba05d31 0x7ff81ba03000 + 11569
34  AppKit                              0x7ff816bea34d 0x7ff816a50000 + 1680205
35  AppKit                              0x7ff8176d7e59 0x7ff816a50000 + 13139545
36  CoreFoundation                      0x7ff813427fa6 0x7ff8133ad000 + 503718
37  CoreFoundation                      0x7ff813427eca 0x7ff8133ad000 + 503498
38  CoreFoundation                      0x7ff81342744c 0x7ff8133ad000 + 500812
39  CoreFoundation                      0x7ff813426b32 0x7ff8133ad000 + 498482
40  HIToolbox                           0x7ff81de38829 RunCurrentEventLoopInMode + 292
41  HIToolbox                           0x7ff81de38466 ReceiveNextEventCommon + 201
42  HIToolbox                           0x7ff81de38381 _BlockUntilNextEventMatchingListInModeWithFilter + 66
43  AppKit                              0x7ff816a8ebe5 0x7ff816a50000 + 256997
44  AppKit                              0x7ff81739efe9 0x7ff816a50000 + 9760745
45  AppKit                              0x7ff816a80005 0x7ff816a50000 + 196613
46  libwx_osx_cocoau_core-3.2.0.2.1.dylib          0x111366ffa wxGUIEventLoop::OSXDoRun() + 186
47  libwx_baseu-3.2.0.2.1.dylib            0x10faaca2d wxCFEventLoop::DoRun() + 29
48  libwx_baseu-3.2.0.2.1.dylib            0x10f9f83ce wxEventLoopBase::Run() + 158
49  libwx_baseu-3.2.0.2.1.dylib            0x10f9c65f3 wxAppConsoleBase::MainLoop() + 99
50  _core.cpython-310-darwin.so            0x110774c01 meth_wxPyApp_MainLoop(_object*, _object*) + 209
51  libpython3.10.dylib                    0x10e528a4a cfunction_call + 90
52  libpython3.10.dylib                    0x10e4c0704 _PyObject_MakeTpCall + 132
53  libpython3.10.dylib                    0x10e5fb563 call_function + 371
54  libpython3.10.dylib                    0x10e5f2bef _PyEval_EvalFrameDefault + 27983
55  libpython3.10.dylib                    0x10e5ea7af _PyEval_Vector + 383
56  libpython3.10.dylib                    0x10e5fb49f call_function + 175
57  libpython3.10.dylib                    0x10e5f1509 _PyEval_EvalFrameDefault + 22121
58  libpython3.10.dylib                    0x10e5ea7af _PyEval_Vector + 383
59  libpython3.10.dylib                    0x10e5ea612 PyEval_EvalCode + 114
60  Pronterface                            0x10b827609 0x10b823000 + 17929
61  Pronterface                            0x10b827c48 0x10b823000 + 19528
62  dyld                                0x7ff812fc0366 0x7ff812fba000 + 25446

Please see crash reports in the attachments.

xcover.gcode.zip crash_reports.zip

[DivingDuck]

@keefo, thanks for your report. Unfortunately I don't know what caused this error and I neither have a Mac device or your type of printer. The report indicate Graphics hardware encountered an error and was reset: 0x00000001 (what ever that means, this could point into the wrong direction as well)

It is surprising that Pronterface crashes two times at nearly the same position / time after one hour of printing. My first thought was that there is maybe a corrupt gcode file involved, but I can't see how this will crash Pronterface.

Pronterface itself generate a log file. Can you attach the file here? Maybe this can give us some more information. The file is called printrun.log and should be on the same place where you can find the configuration file called printrunconf.ini or .pronsolerc. You can find the location in the Settings menu: -->Settings -->Options -->User Interface and there the setting Log Path should show you where the file is located.

In addition I would try to print the involved gcode file directly from SD-card in the printer. This way you can eliminate the file as a possible problem source.

[rockstorm101]

I am able to finish print of many other models,

• Do I understand correctly that other gcode files print fine it is just this one that doesn't? (Which to me would point more towards the gcode file and less towards Printrun code)

• Were you able to print models longer than 1h before?

• If you downgrade to Printrun 2.0.1, are you able to print this gcode file?

[keefo]

I can answer few questions above:

1. Do I understand correctly that other gcode files print fine it is just this one that doesn't? Correct.

2. Were you able to print models longer than 1h before? Yes.

3. In addition I would try to print the involved gcode file directly from SD-card in the printer. This way you can eliminate the file as a possible problem source. If I move the xcover.gcode to sd card and print on my printer, it works, no issue.

I will try to get logs and upload here.

[volconst]

2. Were you able to print models longer than 1h before? Yes.

May be this is some memory leak in the GPU memory, e.g gpusSubmitDataBuffers fails to release the old buffer data. Being able to print longer files does not support this idea, but still possible.

Another possibility is the vector data provided to opengl to be wrong. This could be tested by removing most of the contents of the file and leaving only the initialization and the printing of the object around the height (Z coordinate) around the problem occurs. Print the file without loading filament. If the cut file does not give error, then it may be memory leak. If error, then bad vector data.

[keefo]

I did another print, this time it crash around 1h 15mins. The same crash call stack. Here is the log, nothing useful I can see.

printrun.log.zip

[DivingDuck]

I did some tests today with the provided gcode. I printed the part 3 times under different condition (the way like@volconst mentioned w/o filament and low temps). The first print I simply print the gcode (I changed the temperature values in the file to 30°C). No problem, so the gcode in general seems to be ok. In second attempt I increase the load on Pronterface and the serial communication by enabling the communication debugging in Pronterface. The print went well again. In third attempt I increased in addition the print speed to 300% to generate more traffic for Pronterface and the serial communication. Same result. On a Windows system with my printer I can't replicate the problem.

Looking on the attached log file It didn't show any useful information. Can you enable debug communication ( -->Settings -->Debug communications). 2024-05-31 14:26:19,674 - ok N147743 P0 B15 is line 148918 in the gcode file. There is nothing wrong with the next lines following.

One additional test. I have a build with macOS 11 in my repository. Maybe worth to check as well. It is based on the same code but build with a macOS-11 environment. It should be the same as the build with macOS12, but who knows if there is something different. Here is the link to the file: https://github.com/DivingDuck/Printrun/actions/runs/9286412163

[neofelis2X]

I did a simulation of the file with the mock-printer. The opengl output of printrun should be the same. No crash and it finished without problems. (macOS 12.7.4 with Intel Graphics, Printrun 2.1.0)

May be this is some memory leak in the GPU memory, e.g gpusSubmitDataBuffers fails to release the old buffer data. Being able to print longer files does not support this idea, but still possible.

Another possibility is the vector data provided to opengl to be wrong.

Apple abandoned OpenGL a while ago, so their drivers are not always... great, to say the least. It might be a bug in the driver for this specific AMD Radeon X5000.

[keefo]

I suspect it is the the main visualization cause the crash, I will turn it off and print to see how it goes.
I am printing a large part now, will update here tmr.

[keefo]

I can confirm if I disable main visualization. It does not crash.

[volconst]

@keefo try this test - double click the 3d viewer to pop up the advanced viewer and in it use the up/down keys to render layer by layer. test all layers, also from bed to top direction.

[volconst]

I am printing a large part now

the large part could be fine even with 3d viewer.

[keefo]

@keefo try this test - double click the 3d viewer to pop up the advanced viewer and in it use the up/down keys to render layer by layer. test all layers, also from bed to top direction.

I did try this, no crash, everything is fine. I think the crash only occur during main 3d view render green part. Is there way to dry run the print without connect to a printer?

[volconst]

Is there way to dry run the print without connect to a printer?

Use this as printer https://github.com/kliment/Printrun/blob/master/testtools/mock-printer.py instructions inside

[DivingDuck]

Hello @keefo There is quite some time passed, is there any update for this issue and was you able to make a test via mock-printer?

[DivingDuck]

@rockstorm101, Should we close this issue? I don't see that we can anything do with this issue.

[rockstorm101]

@rockstorm101, Should we close this issue? I don't see that we can anything do with this issue.

Agreed, let's close it. I hope once we migrate to pyglet 2+ every 3D rendering issue will be solved. Nothing to be done really until then other than disabling the 3D viewer.