Bug #598

pssegy: always attempts to open trace list file, even when -T not specified

Added by Adrian about 3 years ago. Updated about 3 years ago.

Status:ClosedStart date:2014-08-11
Priority:NormalDue date:
Assignee:Paul% Done:

100%

Category:-
Target version:Candidate for next minor release
Affected version:5.x-svn Platform:

Description

pssegy fails with message "Cannot find trace list file".

Always attempts to open ", irrespective of whether -T specified or not.
At present pssegy is unusable except on rare occasions when "-Ttrace_list_file" IS specified.

Bug: At src/segy/pssegy.c (line 505-508) attempt to open file is outside of test of whether -T argument has been given (line 514-528)

Fix: Move lines 505-508 within test block 514-528.
See attached patch (apply at top level of GMT tree with -p1)

pssegy.patch Magnifier (1.1 KB) Adrian, 2014-08-11 12:30

Associated revisions

Revision 13458
Added by Paul about 3 years ago

Address issue #598

History

#1 Updated by Paul about 3 years ago

  • Status changed from New to In Progress
  • Assignee set to Paul
  • Target version set to Candidate for next minor release

Thanks for the patch. However, I do not see how that section can be active if Ctrl→T.active is false. The second test of opening the file cannot happen if the first term is false and they are connected with logical AND. If that were true it would first fail on line 289. So I smell some other problem.
I can certainly apply your fix which is reasonable, but now I am curious if there is something else going on. What is your command line, what shell, and what OS, etc? Are you able to upload a small test file and command that fails for you so I can try to reproduce it?

#2 Updated by Adrian about 3 years ago

The error has occurred for me on OSX Mavericks (clang), Ubuntu 14.04, RHEL6 32 & 64 bit (gcc).

Here are some generic commands with output - note that I don't even provide an input segy file or capture output:

Case 1 - should work
$> pssegy -R0/1/0/1 -JX10 -W -D1
pssegy: Cannot find trace list file (null)

Case 2 - should fail at line 289 with message "Syntax error: Option -T requires a file name"
$> pssegy -R0/1/0/1 -JX10 -W -D1 -T
pssegy: Cannot find trace list file

Case 3 - should fail at line 290 with message "Syntax error: Cannot file file junk"
$> pssegy -R0/1/0/1 -JX10 -W -D1 -Tjunk
pssegy: Cannot find trace list file junk

So, you are correct that the tests at 289 & 290 are failing in cases 2 & 3.
Case 1 will always occur without the patch I submitted.

I added some debugging tests just before line 289:
test 1, equiv to line 289
if (Ctrl→T.active && !Ctrl→T.file) {
fprintf(stderr, "caught on ! '%s' '%d'\n",Ctrl→T.file, Ctrl→T.active ); /*test 1*/
}
test 2: use strlen
if (Ctrl→T.active && strlen(Ctrl→T.file) == 0) {
fprintf(stderr, "caught on strlen '%s' '%d'\n",Ctrl→T.file, Ctrl→T.active );
}

For -T without arg (case 2).
test 1 - fails because empty string evaluates as true
test 2 - succeeds because length is zeroi
⇒ tests fail because null terminator in Ctrl-T.file ? ⇒ does not evaluate to false?

For -T with arg (case 3).
The !access() test at 290 also fails (case 3) but I am not sure why.

#3 Updated by Adrian about 3 years ago

Line 289 - no arg test
Ok, I rewrote test 2 above to print the octal value Ctrl→T.file[0
if (Ctrl->T.active && strlen(Ctrl->T.file) == 0) {
fprintf(stderr, "caught strlen '%o'\n",Ctrl->T.file[0] );
}

The output is '0'.
$> pssegy -R0/1/0/1 -JX10 -W -D1 -T
caught strlen '0'

So the reason line 289 fails is because the string always has a null character and "\0" is not false.
.

line 290 - file existence test
access( char*, R_OK) returns -1 on failure, 0 on success [[http://pubs.opengroup.org/onlinepubs/009695399/functions/access.html]]
So, when file is missing:
!access() ⇒ !-1 ⇒ FALSE@ ⇒ no error caught
and, when file is present:
!access() ⇒ !0 ⇒ TRUE@ ⇒ error caught when there is none

Adding the following line
fprintf(stderr, "access '%d'\n", access(Ctrl->T.file, R_OK ));

And running the following demonstrates the issue
$>pssegy -R0/1/0/1 -JX10 -W -D1 -Txxxx
access '-1'
pssegy: Cannot find trace list file xxxx
$> touch xxxx
$>pssegy -R0/1/0/1 -JX10 -W -D1 -Txxxx
access '0'
pssegy: Syntax error: Cannot file file xxxx

N.B. I Think you will find the same issues exist in pssegyz

#4 Updated by Paul about 3 years ago

Sorry, this makes no sense. When I run this on Mavericks there are no such issues because Ctl→T.file is NULL and Ctrl→T.active is false and nothing can happen unless your compiler has gone crazy. Ctrl→T.file0 is never checked since file is NULL. Why is your Ctrl→T.active true? What GMT5 version are you running? What does
pssegy -
return
Are we looking at two very different versions? I am looking at svn r13456. (5.1.2 svn).

#5 Updated by Adrian about 3 years ago

Hi, I am running 5.1.1 - I checked the commits and pssegy.c was last updated for 5.1.1

I have just recompiled on Ubuntu 14.04 (gcc 4.8.2) this morning and get the same issues. So I've now seen this on clang & gcc, linux and osx, 32 & 64 bit. My compilations and those run by our Unix admin.

I think I have confused you a bit with my "diagnostics"

Case 1: No -T
  • Ctrl→T.active = False, Ctrl→T.file = NULL
  • l289 & l290 test skipped correctly
  • fails erroneously at l505
  • fix is the initial patch I submitted
Case 2: -T given without arg
  • Ctrl→T.active = True, Ctrl→T.file = "\0"
  • l289 test does not catch because Ctrl→T.file is not NULL it is an empty string
  • !Ctrl→T.file ⇒ !"\0" ⇒ false
  • l289 conditions are true & false, should be true & true
  • l290 test does not catch because access("\0", R_OK) returns -1 i.e. !-1 is False
  • l290 conditions are True & True & False, should be True, False, False
  • fails at l505
Case 3: -Tfname but fname does not exist
  • Ctrl→T.active = True, Ctrl→T.file = "fname"
  • l289 ok
  • l290 does not catch because access("fname", R_OK) returns -1 i.e. !-1 is False
  • l290 conditions are True & True & False, should be True, True, True
  • fails at l505
Case 4: -Tfname and fname does exist
  • Ctrl→T.active = True, Ctrl→T.file = "fname"
  • l289 ok
  • l290 catches non-existent error because access("fname", R_OK) returns 0 i.e. !0 is True
  • l290 conditions are True & True & True, should be True, True, False

The following versions of the l289 and l290 sanity checks would work

n_errors += GMT_check_condition (GMT, Ctrl->T.active && (!Ctrl->T.file || strlen(Ctrl->T.file) < 1), "Syntax error: Option -T requires a file name\n");
n_errors += GMT_check_condition (GMT, Ctrl->T.active && Ctrl->T.file && access (Ctrl->T.file, R_OK) != 0, "Syntax error: Cannot file file %s\n", Ctrl->T.file);

#6 Updated by Paul about 3 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

Hi Adrian, yes, I think I focused solely on the case 1 "no -T option at all", which cannot and does not fail on my systems. I agree with your other cases which I can reproduce and I have fixed them in r13458. Let me know if your cases now work.

#7 Updated by Paul about 3 years ago

  • Status changed from Resolved to Closed

Closing as fixed since no further feedback received.

Also available in: Atom PDF