php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #35594 getopt() only usable once - with long options built in, causes segfault
Submitted: 2005-12-08 03:56 UTC Modified: 2005-12-08 07:23 UTC
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:2 (100.0%)
From: rabbitt at gmail dot com Assigned:
Status: Closed Package: Reproducible crash
PHP Version: 4.4.1 OS: Linux 2.6.13
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: rabbitt at gmail dot com
New email:
PHP Version: OS:

 

 [2005-12-08 03:56 UTC] rabbitt at gmail dot com
Description:
------------
Without long options built into zif_getopt(), zif_getopt()'s calls to getopt() will only return a populated result once. The reason for this is that 'optind' does not get reset on each call to getopt(). optind is used to keep track of the most option processed internally in getopt(). Once getopt() has finished processing the options, optind remains at the last value it was set to (typically, at this point, optind == argc). 

The problem with this is that when getopt() is called a second time, it thinks that it's already finished with processing the options due to optind being equal to argc. Worse still, with long optoins built in (-DHARTMUT_0), it causes a segfault in glibc's getopt.c (function: _getopt_internal_r() - line 521 specifically).



Reproduce code:
---------------
create file called test.php and add:

<?php
    print_r(@getopt('t', array('test')));
    print_r(@getopt('t', array('test')));
?>


then run: 
php test.php -t

Expected result:
----------------
Array
(
    [t] =>
)
Array
(
    [t] =>
)


Actual result:
--------------
One of two things will happen:

Array
(
    [t] =>
)
Array
(
)


or:

Array
(
)
Segmentation fault (core dumped)

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-12-08 03:58 UTC] rabbitt at gmail dot com
The following patch appears to fix the problem:

--- ext/standard/basic_functions.c      2005-12-07 20:41:49.000000000 -0500
+++ ext/standard/basic_functions.c      2005-12-07 20:44:59.000000000 -0500
@@ -1597,6 +1597,9 @@
        /* Disable getopt()'s error messages. */
        opterr = 0;

+       /* Force reinitialization of getopt() (via optind reset) on every call. */
+       optind = 0;
+
        /* Invoke getopt(3) on the argument array. */
 #ifdef HARTMUT_0
        while ((o = getopt_long(argc, argv, options, longopts, &longindex)) != -1) {
 [2005-12-08 04:01 UTC] rabbitt at gmail dot com
Additional note: I found this bug on 4.3.12, 4.4.1, and 5.0.5.
 [2005-12-08 04:26 UTC] iliaa@php.net
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.


 [2005-12-08 07:23 UTC] rabbitt at gmail dot com
While I appreciate the quickness with which you replied, as well as applying the patch I provided, I should note that, after having researched this bug a bit more, it might be a bit hasty to conclude that my patch is a perfect fix. 

It seems that the static (struct _getopt_data) variable 'getopt_data' is having it's member's (__nextchar) data overwritten in memory somehow during the call to efree() in free_argv() (ext/standard/basic_functions.php line 1430). While my patch enables the resetting of getopt_data, it is probably best to not consider it a safe transaction as, by that point, the memory address might have been usurped already by something else. Although I haven't been able to detect any problems with setting optind to zero (which causes getopt_data to be reinitialized and __nextchar set to NULL), it might be best to look into why the getopt_data.__nextchar is getting overriden in the first place by someone with a more intimate understanding of php internals.

Again, thanks for the speedy response and resolution - as well as all the hard work you all have done making this such a great language!

--
Carl P. Corliss
 [2018-05-16 06:46 UTC] kaishos at yahoo dot com
It seems to have worked abit, but now in php 7.0 ít seems to have this same bug again
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 16:01:29 2024 UTC