Pstext failing (when it used to work)

Q&A
1

Almost posted this to github, but thought maybe an explanation is all I need.

Given this text string: txt_ds="ATL03_20200626034717_00120806_006_01.h5/beam: gt3l"

pstext returns an error if you try to do something like this:

echo "1 1 $txt_ds" | gmt pstext -JX11i/8.5i -R0/11/0/8.5 -F+f8,2+jBL -X-1i -Y-1i > $OUTMAP
ERROR: Caught signal number 4 (Illegal instruction: 4) at
0 libsystem_c.dylib 0x00007ff81cb8fd4a __chk_fail_overflow + 16
1 libsystem_c.dylib 0x00007ff81cb8fd4a __chk_fail_overflow + 16
Stack backtrace:
0 libgmt.6.5.0.dylib 0x000000010d76e478 gmt_sig_handler_unix + 216
1 libsystem_platform.dylib 0x00007ff81cc985ed _sigtramp + 29
2 gmt 0x000000010d03029f GMT_version.version + 17055
3 libsystem_c.dylib 0x00007ff81cb2169e stpcpy + 0
4 libgmt.6.5.0.dylib 0x000000010d6d3feb gmtio_ascii_input + 2907
5 libgmt.6.5.0.dylib 0x000000010d691e54 gmtapi_get_record_fp_sub + 68
6 libgmt.6.5.0.dylib 0x000000010d6914b6 gmtapi_get_record_fp_first + 38
7 libgmt.6.5.0.dylib 0x000000010d66bff2 GMT_Get_Record + 98
8 libgmt.6.5.0.dylib 0x000000010da00ebc GMT_pstext + 5260
9 libgmt.6.5.0.dylib 0x000000010d674ab5 GMT_Call_Module + 2693
10 gmt 0x000000010d026392 main + 2018
11 dyld 0x00007ff81c91141f start + 1903

Is the latest GMT version (6.5.0_274eb0d_2023.11.15) being pickier about having a slash or a colon? I’ve tried escaping those characters and I get the same result.

Did I miss a memo on a change to pstext, or is something amiss? I’ve been using this kind of command for years without issues.

2

Gmt now “careful” examines the very first record to learn if there are things like absolute time strings (users often forget -f0T for instance) so we can that record and set things internally. Unfortunately, the section that checks if a valid date-time stamp had some issues, now fixed. More work will be put into this function to avoid such crashes.

3

Thanks, Paul. A little bit hard to interpret what “careful” GMT means.

Do I need to go back to an older version?

Or is someone on the team going to make sure that pstext can take anything a user sends to it, without crashing? I need that file name (with internal date stamp included) printable on my graphics.

4

Bug fixed but nobody has approved the PR yet…

5

Thanks Paul. Standing by…

I had downloaded latest version about 30 minutes ago, and found it still failed. No worries - have lots of other things to do!

6

Now merged.

7

Oh boy. I updated GMT to latest merged version. Still not quite there…

Using my original text string, pstext operates without complaints, placing it right where it belongs.

Then, I tried changing the text string passed to pstext, to: txt_ds="Test print", and I get this error message back from pstext: pstext [ERROR]: Unacceptable date template ddmmmmyyyy. Yikes! Didn’t crash, but pstext is unhappy.

Ah, it seems to be anything that starts with an upper case T, pstext doesn’t like.

Sorry Paul, something is still amiss.

8

OK, after dinner.

9

Sorry too late (tomorrow).

10

No worries, Paul. We’ll get there!

11

New branch added (text-fix) - if you can build from that one you can see if you can break it.

12

Now merged into master.

13

Seems to work for both of my test strings, in the merged version - but pstext is now reporting (to STDOUT, without my asking): ncol = 2

Even adding -Vq fails to prevent pstext from making that report.

14

Sorry, debugging print. Now gone.

15

Whew! All looks good. Thanks Paul. Go get tea!

16

@John_Geodesy, I’ve completely rewritten the “Detect” functions in GMT that determines if a string is time, longitude, etc. If you build master you could cd to test/gmtconvert and run

gmt convert -/ strings.txt

and look at the output. If you have time, make a file with the same format with some of your cases, say, john,txt and run

gmt convert john.txt

Plese send me anything that fails the test. We wont implement the new functions until we have covered all possible cases.

17

Output from the command, gmt convert -/ strings.txt all looks fine. Let me know if you need to see it.

Creating a john.txt file that looks like this:

> cat john.txt
ATL03_20200626034717_00120806_006_01.h5/beam: gt3l |STRING
Test text |STRING
Some other things that might look like dates: 11-14-2023 |STRING
20231120-Check how this is handled |STRING

Then running:

> gmt convert -/ john.txt
ATL03_20200626034717_00120806_006_01.h5/beam: gt3l        STRING	        STRING
                     Test text        STRING	        STRING
Some other things that might look like dates: 11-14-2023        STRING	        STRING
20231120-Check how this is handled        STRING	        STRING

Everything came out the way I expected. No failures detected, thus far!

18

Thanks for checking John. Just send me any case you find does not work. The new scanner has been sent as PR and will shortly be merged into master.