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 back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
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: Thu Nov 21 12:01:29 2024 UTC