Bug #993
Segmentation fault of pssolar
| Status: | Closed | Start date: | 2016-10-31 | |
|---|---|---|---|---|
| Priority: | Normal | Due 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 over 1 year 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 over 1 year 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 over 1 year ago
They look but not exactly sure what allocating zero elements does to a pointer.
#4
Updated by Paul over 1 year 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.