SEG error in PHP extension

Question

I wrote a PHP extension to access functions in a static lib, I created PHP as CGI, and everything seemed to work (after several days of working on it ..)

Having earned as soon as everything worked, I recompiled PHP without debugging the messages that I had in it. ( php_printf("here111"); .... php_printf("sending arguments..."); )

Then it just stops working. The function that I call in the static lib operation, I tested it by calling it directly from another executable.

I built PHP using debugging symbols ( --enable-debug ) and can debug it to some extent in gdb.

I'm still trying to figure out what happened. It seems that the function in lib ( diffFst ) cannot read the input arguments.

 268 if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ssssssd", 269 &filA, &filA_len, 270 &nomvarA, &nomvarA_len, 271 &filB, &filB_len, 272 &nomvarB, &nomvarB_len, 273 &filO, &filO_len, 274 &newnomvar, &newnomvar_len, 275 &mult 276 ) == FAILURE) { 277 RETURN_LONG(-100); 278 } 279 280 php_printf("Read arguments:\nfilA: %s, nomvara: %s\nfilB: %s, nomvarB: %s\nfilO: %s, nomvarO: %s\nMult: %0.3f\n", 281 filA,nomvarA, filB,nomvarB, filO,newnomvar, mult); 282 285 ier = difffst_(filA,nomvarA, filB,nomvarB, filO,newnomvar, mult); 

When I call this function, the php_printf() statement works and prints the correct values. However, when I let it call the diffffst_ function, I get segfault when it tries to read the input variables.

The diffFst function is written to fortran:

  5 function diffFst(filA, nomvara, filB, nomvarb, filO, newnomvar, change, write_tictac, in_verbose) result(ier) 10 implicit none 11 12 character (len=*), intent(IN) :: filA, filB, filO 13 character (len=*), intent(IN) :: nomvara, nomvarb, newnomvar 14 16 real, intent(IN) :: change 17 logical, intent(IN) :: write_tictac 18 19 logical, intent(IN), optional :: in_verbose 21 logical :: verbose = .false. 27 integer :: ier ... 117 ier = fstouv(iuna, 'RND') 118 IF (ier < 0) THEN 119 if (verbose) write(stderr,'(2A)') "Could not fstouv FST file ", trim(filA) 120 ELSE 121 nmax = fstnbr(iuna); 122 if (verbose) write(stdout,'(3A,I6,A)') "Succesfully opened ", trim(filA), ' with ', nmax, ' records' 123 allocate(liste(nmax)) 124 END IF 

In particular, it does not work on line 122 (according to the debugger) when it tries to read filA .

I do not know why, I tried:

• Creating a Subroutine Function
• Creating a fortran function
• Creating a Pure Function
• Returning the values ​​(what is now, ier = .. )
• Having return in code, removing return
• Tried to print things in stdout and write files

It seems that the data is not being transferred properly. Even in the debugger, I cannot read the arguments.

A depressing thing: at some point, it only worked. I checked file permissions, checked paths, etc. And I can just run the function from the fortran executable.

Is there a trick I'm missing?

thanks

Answer 1

Took the time and needed extra help ( such problems )

Basically, two things should have changed:

• Passing integers by reference
• Accept the correct lines

The first is easy, just ier=func(..., &integer_var, ...)

The second part is about passing the length of the string. There may have been an easier way to do this (by reading the length of the string, looking for \ 0), but they did not work. So now i'm skipping

 ier = func(str,strlen,...) 

Then in Fortran I accept the line as

 character(kind=c_char,len=strlen), intent(IN) :: str 

Specific changes to the fortran code above:

 11 use, intrinsic :: iso_c_binding 12 use interfaces_rmnutils 13 implicit none 16 integer(kind=c_int), intent(IN) :: len_filA, len_filB, len_filO 17 character (kind=c_char,len=len_filA), intent(IN) :: filA 18 character (kind=c_char,len=len_filB), intent(IN) :: filB 19 character (kind=c_char,len=len_filO), intent(IN) :: filO 

When it worked, it must have been before I tried to read the lines in the form (len=*) , and integers were passed as links, so they would have significant values.

Thanks everyone!

Answer 2

Your program seems to expand the stack. Stack corruption usually occurs with improper use of pointers. Check carefully (examine the contents of variables using a debugger or simple traces) right before calls to suspicious functions.