php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #80083 Optimizer pass 6 removes variables used for ibm_db2 data binding
Submitted: 2020-09-10 15:24 UTC Modified: 2020-09-17 08:21 UTC
From: calvin at cmpct dot info Assigned: nikic (profile)
Status: Closed Package: opcache
PHP Version: 7.4.10 OS: IBM i 7.2
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: calvin at cmpct dot info
New email:
PHP Version: OS:

 

 [2020-09-10 15:24 UTC] calvin at cmpct dot info 
Description:
------------
I'm not sure if this is an ibm_db2 module bug or an opcache bug, but I figured I'd report here first.

Script, debug output at different optimization levels, and a diff between them available in this gist (let me know if anything else is needed for repro and I can add to it): https://gist.github.com/NattyNarwhal/09679e177b11de22aeceaaffdc62012b

The summary is when optimizer pass 6 (DFA) runs through the program, it elides the variables used for a data bound stored procedure call using the ibm_db2 extension, resulting in failure. Masking the bit for pass 6 out (that is, setting optimization level 0x7FFEBFFF to 0x7FFEBFDF) is enough to mitigate the failure.

Expected result:
----------------
Résultat : bar (or whatever the stored procedure used sets)

Actual result:
--------------
PHP Warning:  db2_execute(): Value Not Bound in /home/calvin/test/gautier.php on line 31
PHP Warning:  db2_execute(): Binding Error 3 in /home/calvin/test/gautier.php on line 31
Résultat :

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2020-09-10 15:39 UTC] nikic@php.net 
The db2 extension needs to change its API to not work on variable names -- it needs to accept variables by reference instead.
 [2020-09-10 16:53 UTC] calvin at cmpct dot info 
Yeah, I agree this is API is malpractice. (Looking at the db2 binding code and having it manipulate local/global scope symbol tables when no other modules did so was a bit of a head-scratcher.) Changing the db2 API would probably result in a breaking change though, and most code on ibm_db2 instead of (PDO_)ODBC is legacy; so I suspect most users running into this will either detune opcache or migrate to ODBC. (Of course, this is the IBM i perspective. I don't know what LUW people are doing here; perhaps they consider that extension more important.)
 [2020-09-15 12:32 UTC] nikic@php.net 
Agree. I think it's okay for us to hardcode these functions as modifying the symtable in opcache.

Do you know which functions are affected? Is it just db2_execute() that accesses local variables, or also other functions?
 [2020-09-15 17:23 UTC] calvin at cmpct dot info 
I skimmed the source and I think the only symbol table mangling code is in execute called code; though perhaps the bind code in ibm_db2 could also signal something to opcache?. I also didn't know opcache was willing to accept a workaround - has that happened before?
 [2020-09-17 08:11 UTC] nikic@php.net
-Summary: Optimizer pass 6 removes variables used for data binding +Summary: Optimizer pass 6 removes variables used for ibm_db2 data binding
 [2020-09-17 08:14 UTC] nikic@php.net 
Automatic comment on behalf of nikita.ppv@gmail.com
Revision: http://git.php.net/?p=php-src.git;a=commit;h=a4f806aa79c9d0e497866e86f750e87d9bd874f1
Log: Fixed bug #80083
 [2020-09-17 08:14 UTC] nikic@php.net
-Status: Open +Status: Closed
 [2020-09-17 08:21 UTC] nikic@php.net
-Assigned To: +Assigned To: nikic
 [2020-09-17 08:21 UTC] nikic@php.net 
> I skimmed the source and I think the only symbol table mangling code is in execute called code; though perhaps the bind code in ibm_db2 could also signal something to opcache?.

I also just checked the code, and it looks like just handling db2_execute() should be sufficient. While db2_bind_param() accepts the variable name, it doesn't do anything beyond storing it.

> I also didn't know opcache was willing to accept a workaround - has that happened before?

Nope, but doesn't really cost us anything, as long as it's an isolated occurrence...

I've committed a fix now, but haven't tested it, as I don't have the necessary environment.
 [2020-09-17 14:29 UTC] calvin at cmpct dot info 
Thanks. I'll backport it to my 7.4 build soon and see how it goes.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Tue Dec 03 17:01:29 2024 UTC