trevorsandy
commented
2 weeks ago Thank you for reporting this behaviour. I'll take a look.
Cheers,
Open ReneFrijhoff opened 9 months ago
trevorsandy
commented
2 weeks ago Thank you for reporting this behaviour. I'll take a look.
Cheers,
trevorsandy
commented
10 hours ago I am able to reproduce this behaviour and I have determined exactly which call is causing the Heap Corruption Exception (0xC0000374). Unfortunately, after spending the better part of 8 hours trying various solutions, I am unable to correct this behaviour. As you may know, heap corruption exceptions can be quite challenging as the symptom may not at all be the source of the break. With LDGLite, the HC exception is manifesting at line 1163 of LDrawIni/LDrawIni.c LPWSTR WPath = malloc(pathBufSize * sizeof(WCHAR));. I don't believe this is the source of the problem however because several prominent LDraw applications use this exact LDrawIni source code without abnormal behaviour - including LDView and LPub3D.
What is also quite strange is this behaviour does not occur when I run LDGLite from the command console - even after writing a script to loop through 50 image generation calls. However, as you have noticed, when LDGLite is run as a Qt child process from within LPub3D, the heap corruption error always manifests, all-be-it in a somewhat random manner. Sometimes images for several steps/pages are successfully generated before failure, and other times, the abend is immediate. Moreover, this behaviour is not present on Unix systems and, equally, I have not seen any indications of failure on my macOS, Linux and Windows GitHub action builds.
At this point, I am inclined to believe, if a major code revision is not undertaken, LDGLite has reached its end of life. As you may know the original c-program LDLite was written in 1998 when the dominant Windows OS was Windows 95 - I can't imagine what programs originally designed for Windows 95 are still consistently running today.
Lastly, time permitting, I will continue to take a look for now but I an not so optimistic. LDGLite is 26 years old, perhaps it is time to retire.
Regarding another renderer with fast performance, the LPub3D Native renderer, using the LeoCAD engine, is actually faster than LDGLite so I would advise you to use this renderer over LDView for proofing your instruction document.
That's it for now...
Cheers,
DanieleBenedettelli
commented
9 hours ago Trevor, Thanks for all your work
D
Il lun 7 ott 2024, 07:48 Trevor SANDY @.***> ha scritto:
I am able to reproduce this behaviour and I have determined exactly which call is causing the Heap Corruption Exception (0xC0000374). Unfortunately, after spending the better part of 8 hours trying various solutions, I am unable to correct this behaviour. As you may know, heap corruption exceptions can be quite challenging as the symptom may not at all be the source of the break. With LDGLite, the HC exception is manifesting at line 1163 of LDrawIni/LDrawIni.c LPWSTR WPath = malloc(pathBufSize * sizeof(WCHAR));. I don't believe this is the source of the problem however because several prominent LDraw applications use this exact LDrawIni source code without abnormal behaviour - including LDView and LPub3D.
What is also quite strange is this behaviour does not occur when I run LDGLite from the command console - even after writing a script to loop through 50 image generation calls. However, as you have noticed, when LDGLite is run as a Qt child process from within LPub3D, the heap corruption error always manifests, all-be-it in a somewhat random manner. Sometimes images for several steps/pages are successfully generated before failure, and other times, the abend is immediate. Moreover, this behaviour is not present on Unix systems and, equally, I have not seen any indications of failure on my macOS, Linux and Windows GitHub action builds.
At this point, I am inclined to believe, if a major code revision is not undertaken, LDGLite has reached its end of life. As you may know the original c-program LDLite was written in 1998 when the dominant Windows OS was Windows 95 - I can't imagine what programs originally designed for Windows 95 are still consistently running today.
Lastly, time permitting, I will continue to take a look for now but I an not so optimistic. LDGLite is 26 years old, perhaps it is time to retire.
Regarding another renderer with fast performance, the LPub3D Native renderer, using the LeoCAD engine, is actually faster than LDGLite so I would advise you to use this renderer over LDView for proofing your instruction document.
That's it for now...
Cheers,
— Reply to this email directly, view it on GitHub https://github.com/trevorsandy/lpub3d/issues/751#issuecomment-2395961060, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALJJ3TP57D3JOK5NQB6HQG3Z2IODXAVCNFSM6AAAAABOUGLB5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJVHE3DCMBWGA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Subject
LDGLite indicates a crash on the PLI image generation, but generated it anyway
Environment
Configuration
[Note: Provide details and content below as needed with appropriate redactions. To produce the Windows registry extract for an installed distribution, go to the command console and enter the command line shown. The extract file will be placed on your desktop.]
LPub3D installation path
Application data path
Registry Extract
Renderer configuration files Config files.zip
Logs
Screenshots
Screenshots.zip
Steps to reproduce
Load file and export as .png file. Sometimes it crashes and sometimes not, if it crashes (no indication however) the image doesn't display the submodel. When just stepping through, errors will occur, but when stepping a page back and going forward again, no error will occur again and the model is correctly displayed.
Expected behaviour
No error should occur and everything should be rendered.
Actual behaviour
Depending on the use either an error will occur and nothing is rendered 1st time, but when stepping back and going forward again then there is no problem or no error will occur and nothing is rendered see: Steps to reproduce.
Workaround
Stepping through manually (though very time consuming) or using LDView as renderer.