trevorsandy / lpub3d

An LDraw™ editor for LEGO® style digital building instructions.
https://trevorsandy.github.io/lpub3d/
130 stars 19 forks source link

Inserting "Rotate" can cause LPub3D to crash #82

Closed d-j-m-0 closed 5 years ago

d-j-m-0 commented 5 years ago

Subject

When using the 3DViewer within LPub3D to insert a rotation of a part in a sub-model, LPub3D will crash if the sub-model does not also contain a "0 STEP" command.

Environment

Configuration

N/A

Logs

N/A

Screenshots

N/A

Steps to reproduce

The attached zip file contains two simple models; rotate_crash.mpd and rotate_no_crash.mpd. rotate_crash.zip

a.1) Extract "rotate_crash.mpd" a.2) Open it in LPub3D. a.3) Select the "3DViewer - by LegoCAD(C)" tab. a.4) Click on the brick in the viewer. a.5) Select the "Rotate" toolbar icon and rotate the brick in any direction. a.6) Click the "Insert ROTSTEP" toolbar icon. a.7) LPub3D crashes.

b.1) Extract "rotate_no_crash.mpd" b.2) Open it in LPub3D. b.3) to b.6) As per a.3 to a.6) above. b.7) LPub3D rotates the model successfully.

Expected behaviour

For both models, the part should be successfully rotated.

Actual behaviour

See step a.7) above.

Workaround

Ensure the sub-model contains a "0 STEP" command.

Solution suggestion

N/A

trevorsandy commented 5 years ago

Corrected.

Using line number, derived from page location, as an array index without first checking if the index is less than number of lines. In cases where the model file is well formatted and files end with STEP or NOSTEP meta, the line number index (page location) will be less than the number of lines in the file as the ending meta is not a valid page. However, if there is no ending meta, the line number index will be equal to the number of lines in the file and; therefore, will overrun the array.

StyletX commented 5 years ago

Hi! Pressing the button "Apply ROTSTEP" again crash Lpub3d... v.2.3.1 Ubuntu 18.04.1

Crash.zip

trevorsandy commented 5 years ago

v2.3.1 is not yet released - the backward navigation button behaviour was broken so I did not complete the release.

The behaviour you are experiencing is sourced from the space in the model name. Change 'exo h' to 'exo_h' to avoid the abnormal program end.

I'll take a look at treating this limitation in the next release. 2.3.1 is just about ready to release and I'd rather not delay any further.

Cheers,

trevorsandy commented 5 years ago

@StyletX, I went ahead and included the fix in 2.3.1.1 See #119

Cheers,