|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #59545 Calling bbcode_parse() multiple times creates different output
Submitted: 2010-12-21 09:35 UTC Modified: 2017-04-01 19:32 UTC
Avg. Score:4.5 ± 0.5
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:2 (100.0%)
From: emiel dot bruijntjes at copernica dot com Assigned:
Status: Wont fix Package: bbcode (PECL)
PHP Version: 5.3.2 OS: Ubuntu
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2010-12-21 09:35 UTC] emiel dot bruijntjes at copernica dot com
I think something is wrong with the internal memory 
management of the elements that are added to the bbcode 
parser. We have a website with multiple items that make use 
of bbcode. We create a single bbcode resource, add elements 
and smilies to it, and then call bbcode_parse() a couple of 
times in a row to convert bbcode'd text into HTML.

However: the output of bbcode_parse() is not always the 
same: sometimes the [url] tags are converted into <a href> 
tags, but at other times the method returns the original 
bbcode, and does not do any conversion at all.

I have created a tiny example script to reproduce the 
problem. I am aware that this script does not make much 
sense in a standalone environment, it is just the smallest 
possible example in which I run into this problem. (Thus: 
yes I know it is odd to call bbcode_add_element for elements 
that are already registered, but even if I do, it should not 
cause this unexpected behavior)

Reproduce code:
function handleUrlParameter($param, $content)
    return $content;

$options = array(
    'sub'   =>  array(
                    'type'              =>  BBCODE_TYPE_NOARG,
                    'open_tag'          =>  '<b>',
                    'close_tag'         =>  '</b>',
    'img'   =>  array(
                    'type'              =>  BBCODE_TYPE_OPTARG, 
    'url'   =>  array(
                    'type'              =>  BBCODE_TYPE_OPTARG, 
                    'open_tag'          =>  '<a href={PARAM}>', 
                    'close_tag'         =>  '</a>', 
                    'param_handling'    =>  'handleUrlParameter', 

$parser = bbcode_create($options);
$text = "this is an [url=]example link[/url].\n";

for ($i=0; $i<1000; $i++)
    foreach ($options as $tag => $option) bbcode_add_element($parser, $tag, $option);
    echo(bbcode_parse($parser, $text));

Expected result:
I would expect 1000 lines with the text:

this is an <a href=>example link</a>.

Actual result:
I get to see two possible results:

this is an <a href=>example link</a>.
this is an [url=]example link[/url].


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2010-12-21 09:44 UTC] xdecock at gmail dot com
By doing this, you are adding multiple times the same rules to the bbcode parser, indeed it can create some confusion, and i won't be surprised if it created memory leaks, i'll do a double check around existing tags being re-added, 

But the bbcode_add_element($parser,$tag, $option);

Should only be called "once" per tag, so, outside of the loop.

Can you confirm the bug exists with the following code?

(Don't have a test-env at hand)

$parser = bbcode_create($options);
$text = "this is an [url=]example link[/url].\n";

foreach ($options as $tag => $option) bbcode_add_element($parser,$tag, $option);

for ($i=0; $i<1000; $i++)
    echo(bbcode_parse($parser, $text));
 [2010-12-21 14:40 UTC] emiel dot bruijntjes at copernica dot com
Thank you for your very fast reply. Removing that does 
indeed take away the problem. But that is not a workable 
solution for us, as the script was just a demonstration that 
there is a memory problem in the bbcode extension, and not a 
demonstration of a very efficient and smart use of the 
bbcode extension :).

We are using this extension on a website with many texts 
that all have bbcode in them. What we do is this: we first 
create the parser with all the elements, add smilies, and 
then we call bbcode_parse(...) a number of times for all 
texts on the page.

However: it turns out that by doing this, we caused the 
apache process to crash with a segmentation fault once in a 
while. It just crashed, and the php error log was filled 
with strange errors like "function `xxx' is not a function 
name", where xxx was some substring out of the text being 
parsed. Sadly, I have not managed to create a reproducable 
situation that triggers this error.

We could work around this problem by re-adding the elements 
that use callback functions right before each call to 
bbcode_parse. That is indeed odd and should not be 
necessary, but it did solve the segmentation fault problem. 
But today I found out that now suddenly some articles are 
not being parsed and still show the original bbcode instead 
of the html code. The script that I posted with my original 
bug report is just a small demonstration of this problem.

What is also strange: if you change the example script 
slightly, and add a 'b' tag instead of a 'sub' tag, the 
problem is gone too! It really looks like a buffer overflow 
or accidental memory deallocation.

I really hope the problem can be solved. Our current 
workaround is to setup a new parser for every single text 
that needs to be parsed. But this is not very efficient 
because we have so many smilies that we have to loop over.
 [2010-12-21 16:24 UTC] xdecock at gmail dot com
Indeed, for your production settings, i'll strongly recommand recreating the base parser, as adding all element everytime will be even less efficient :)

I'll try to investigate this asap.

Thanks a lot for your feedback,


What version of the extension are you using?
 [2010-12-22 04:25 UTC] emiel dot bruijntjes at copernica dot com
Hi Xavier,

The problem occurs on both the current stable and the current 
beta release, 1.0.2 and 1.0.3b1.

 [2017-04-01 19:32 UTC]
-Status: Open +Status: Wont fix
 [2017-04-01 19:32 UTC]
Due to this extension not seeing any activity since 2010, this issue will not be fixed. We are therefore closing this now.
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Mon Oct 25 08:03:33 2021 UTC