# Psxy -g option with binary data **URL:** \ **Category:** Q&A\ **Created:** [July 16, 2021, 5:10pm UTC](https://forum.generic-mapping-tools.org/t/psxy-g-option-with-binary-data/1899 "2021-07-16T17:10:46Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![John\_Geodesy](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/john_geodesy/32/116_2.png) [@John\_Geodesy](https://forum.generic-mapping-tools.org/u/John_Geodesy)\ **Post date:** [July 16, 2021, 5:10pm UTC](https://forum.generic-mapping-tools.org/t/psxy-g-option-with-binary-data/1899/1 "2021-07-16T17:10:46Z")
I probably should enter this as a bug report on the github page, but I can’t seem to locate it! Running version: Version 6.3.0\_6065f93\_2021.07.07 It seems that a segmentation fault error (11) gets issued when feeding a two-column binary file to psxy with the option -gxgap, where “gap” is a number. The same -g option works fine with a text version (i.e., after sending the binary file through gmtconvert). psxy works fine with my binary file, when -gx option is omitted. Given this data (in text format, note the gap in the x-coord data, after 394.994): ``` 394.989 1168.18 394.99 1168.18 394.991 1168.19 394.992 1168.2 394.993 1168.25 394.994 1168.33 395.075 1168.03 395.076 1168.28 395.077 1168.25 395.078 1168.23 395.079 1168.22 395.08 1168.21 395.081 1168.2 395.082 1168.19 395.083 1168.19 ``` Save this data as t.txt, and run psxy -gx, for example: `gmt psxy -JX9i/6.5i -R394.95/395.1/1167.5/1168.5 t.txt -W1p -Bxag -Byag -BWeSn -gx0.01 > t.ps` That works just fine. But, if you convert this sample data to binary (e.g., gmt gmtconvert t.txt -bo2d \> t.bin), then run it, like this, you’ll get a segment fault result: ``` > gmt psxy -JX9i/6.5i -R394.95/395.1/1167.5/1168.5 -bi2d t.bin -W1p -Bxag -Byag -BWeSn -gx0.01 > $OUTMAP ERROR: Caught signal number 11 (Segmentation fault: 11) at 0 libgmt.6.dylib 0x000000010c0aae40 gmtlib_read_table + 1920 1 ??? 0x0000000000000000 0x0 + 0 Stack backtrace: 0 libgmt.6.dylib 0x000000010c01e8f2 sig_handler + 594 1 libsystem_platform.dylib 0x00007fff6ab9c5fd _sigtramp + 29 2 ??? 0x0000000117f08b8d 0x0 + 4696607629 3 libgmt.6.dylib 0x000000010c04f32a gmtapi_import_data + 4986 4 libgmt.6.dylib 0x000000010c03abcc gmtapi_get_data + 348 5 libgmt.6.dylib 0x000000010c031f42 GMT_Read_Data + 3970 6 libgmt.6.dylib 0x000000010c3b9f2a GMT_psxy + 14266 7 libgmt.6.dylib 0x000000010c042f82 GMT_Call_Module + 2162 8 gmt 0x000000010c008573 main + 1459 9 libdyld.dylib 0x00007fff6a9a3cc9 start + 1 ``` ---
**Author:** ![pwessel](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/pwessel/32/30_2.png) [@pwessel](https://forum.generic-mapping-tools.org/u/pwessel)\ **Post date:** [July 16, 2021, 10:30pm UTC](https://forum.generic-mapping-tools.org/t/psxy-g-option-with-binary-data/1899/2 "2021-07-16T22:30:05Z")
Fix submitted to GitHub: [https://github.com/GenericMappingTools/gmt/pull/5485](https://github.com/GenericMappingTools/gmt/pull/5485). To report bugs, please go directly to [https://github.com/GenericMappingTools/gmt/issues](https://github.com/GenericMappingTools/gmt/issues). ---
**Author:** ![pwessel](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/pwessel/32/30_2.png) [@pwessel](https://forum.generic-mapping-tools.org/u/pwessel)\ **Post date:** [July 17, 2021, 1:48am UTC](https://forum.generic-mapping-tools.org/t/psxy-g-option-with-binary-data/1899/3 "2021-07-17T01:48:25Z")
Now merged into master. ---
**Author:** ![John\_Geodesy](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/john_geodesy/32/116_2.png) [@John\_Geodesy](https://forum.generic-mapping-tools.org/u/John_Geodesy)\ **Post date:** [July 19, 2021, 2:22pm UTC](https://forum.generic-mapping-tools.org/t/psxy-g-option-with-binary-data/1899/4 "2021-07-19T14:22:27Z")
Thanks, Paul. I updated GMT on my system and bookmarked the GitHub site. Anything else buggy that I might find, I’ll direct it to GitHub.