Bug #993

Segmentation fault of pssolar

Added by Dongdong 7 months ago. Updated 7 months ago.

Status:ClosedStart date:2016-10-31
Priority:NormalDue date:
Assignee:Paul% Done:

100%

Category:-
Target version:Candidate for next bugfix release
Affected version:5.3-svn Platform:

Description

The script below is modified from example 46 (http://gmt.soest.hawaii.edu/doc/latest/gallery/ex46.html).
In fact, I only changed the date from 2016-02-09T16:00:00 to 2016-02-23T03:00:00:

ps=example_46.ps
gmt pscoast -Rd -JKs0/10i -Dl -A5000 -W0.5p -N1/0.5p,gray -S175/210/255 -Bafg --MAP_FRAME_TYPE=plain -K -Xc > $ps
gmt pssolar -R  -J -Td+d2016-02-23T03:00:00 -Gnavy@95 -K -O >> $ps
gmt pssolar -R  -J -Tc+d2016-02-23T03:00:00 -Gnavy@85 -K -O >> $ps
gmt pssolar -R  -J -Tn+d2016-02-23T03:00:00 -Gnavy@80 -K -O >> $ps
gmt pssolar -R  -J -Ta+d2016-02-23T03:00:00 -Gnavy@80 -K -O >> $ps
gmt pssolar -I+d2016-02-23T03:00:00 -C | gmt psxy -R -J -Sksunglasses/1.5c -Gyellow -O >> $ps

Then pssolar exits with segmentation fault.

$ sh ./example_46.sh                                                                    1 ↵
ERROR: Caught signal number 11 (Segmentation fault) at
/opt/GMT-5.3.1/lib64/libgmt.so.5(gmt_geo_polarcap_segment+0x567)[0x7f45a66a5c97]
[0xfffffffffffffff8]
Stack backtrace:
/opt/GMT-5.3.1/lib64/libgmt.so.5(sig_handler+0x24f)[0x7f45a656f04f]
/lib64/libc.so.6(+0x35670)[0x7f459ff99670]
/opt/GMT-5.3.1/lib64/libgmt.so.5(gmt_geo_polarcap_segment+0x567)[0x7f45a66a5c97]
/opt/GMT-5.3.1/lib64/libgmt.so.5(gmt_geo_polygons+0x87d)[0x7f45a66a66bd]
/opt/GMT-5.3.1/lib64/libgmt.so.5(GMT_pssolar+0x1095)[0x7f45a6802875]
/opt/GMT-5.3.1/lib64/libgmt.so.5(GMT_Call_Module+0x115)[0x7f45a657b535]
gmt(main+0x692)[0x4012e2]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f459ff85b15]
gmt[0x40150d]
ERROR: Caught signal number 11 (Segmentation fault) at
/opt/GMT-5.3.1/lib64/libgmt.so.5(gmt_geo_polarcap_segment+0x567)[0x7f1f669d4c97]
[0xfffffffffffffff8]
Stack backtrace:
/opt/GMT-5.3.1/lib64/libgmt.so.5(sig_handler+0x24f)[0x7f1f6689e04f]
/lib64/libc.so.6(+0x35670)[0x7f1f602c8670]
/opt/GMT-5.3.1/lib64/libgmt.so.5(gmt_geo_polarcap_segment+0x567)[0x7f1f669d4c97]
/opt/GMT-5.3.1/lib64/libgmt.so.5(gmt_geo_polygons+0x87d)[0x7f1f669d56bd]
/opt/GMT-5.3.1/lib64/libgmt.so.5(GMT_pssolar+0x1095)[0x7f1f66b31875]
/opt/GMT-5.3.1/lib64/libgmt.so.5(GMT_Call_Module+0x115)[0x7f1f668aa535]
gmt(main+0x692)[0x4012e2]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f1f602b4b15]
gmt[0x40150d]

History

#1 Updated by Joaquim 7 months ago

Yep, for the current example and for -Tn or -Ta, in gmt_plot.c#L5640

/* 1. Calculate the path from yc to pole: */
perim_n = gmtlib_lonpath (GMT, start_lon, pole_lat, yc, &x_perim, &y_perim);

perim_n = 0 and troubles follow. In this case pole_lat yc 90, so maybe just needs a test to catch these type of cases.

#2 Updated by Paul 7 months ago

  • Status changed from New to Feedback

So is x_perim and y_perim NULL then? I could add a check to avoid the memcpy of those vectors.

#3 Updated by Joaquim 7 months ago

They look but not exactly sure what allocating zero elements does to a pointer.

#4 Updated by Paul 7 months ago

  • Status changed from Feedback to Resolved
  • Assignee set to Paul
  • Target version set to Candidate for next bugfix release
  • % Done changed from 0 to 100

I think this is now fixed in r17298. Dongdong's example works for me.

#5 Updated by Paul 7 months ago

  • Status changed from Resolved to Closed

Seems to be fixed.

Also available in: Atom PDF