DQL does not work when setlocale(LC_ALL, 'tr_TR'); was called before #4948

New Issue

admin · 2026-01-22T14:53:42+01:00

admin commented

2026-01-22 14:53:42 +01:00

Originally created by @AnnaDamm on GitHub (Dec 18, 2015).

When you set the locale with setlocale for specific languages before using DQL, the Lexer splits the tokens wrong:

(inside a ProductGroupMemberRepository EntityRepository class)

    setlocale(LC_ALL, 'tr_TR');

    $qb   = $this->createQueryBuilder('m');
        $expr = $qb->expr();

        $qb->select('p')
            ->innerJoin('Entity\Product', 'p', 'WITH', 'm.productId = p.id')
            ->where($expr->eq("m.groupId", ":groupId"))
            ->setParameter(":groupId", $groupId);
    return $qb->getQuery()->getResult();

It breaks with the error message: Error: Expected end of string, got 'I'
After some debugging, I found that preg_split apparently works differently on tr_TR. it splits on different characters:

array(36) {
  [0]=>
  array(2) {
    [0]=>
    string(6) "SELECT"
    [1]=>
    int(0)
  }
  [1]=>
  array(2) {
    [0]=>
    string(1) "p"
    [1]=>
    int(7)
  }
  [2]=>
  array(2) {
    [0]=>
    string(4) "FROM"
    [1]=>
    int(9)
  }
  [3]=>
  array(2) {
    [0]=>
    string(40) "Entity\ProductGroupMember"
    [1]=>
    int(14)
  }
  [4]=>
  array(2) {
    [0]=>
    string(1) "m"
    [1]=>
    int(55)
  }
  [5]=>
  array(2) {
    [0]=>
    string(1) "I"
    [1]=>
    int(57)
  }
  [6]=>
  array(2) {
    [0]=>
    string(4) "NNER"
    [1]=>
    int(58)
  }
  [7]=>
  array(2) {
    [0]=>
    string(2) "JO"
    [1]=>
    int(63)
  }
  [8]=>
  array(2) {
    [0]=>
    string(1) "I"
    [1]=>
    int(65)
  }
  [9]=>
  array(2) {
    [0]=>
    string(1) "N"
    [1]=>
    int(66)
  },
...

If I use setlocale with LC_NUMERIC or comment the line out, or use other languages, everything works fine. Even though the regex and DQL are exactly the same thing.

Originally created by @AnnaDamm on GitHub (Dec 18, 2015). When you set the locale with `setlocale` for specific languages before using DQL, the Lexer splits the tokens wrong: (inside a ProductGroupMemberRepository EntityRepository class) ``` php setlocale(LC_ALL, 'tr_TR'); $qb = $this->createQueryBuilder('m'); $expr = $qb->expr(); $qb->select('p') ->innerJoin('Entity\Product', 'p', 'WITH', 'm.productId = p.id') ->where($expr->eq("m.groupId", ":groupId")) ->setParameter(":groupId", $groupId); return $qb->getQuery()->getResult(); ``` It breaks with the error message: `Error: Expected end of string, got 'I'` After some debugging, I found that preg_split apparently works differently on tr_TR. it splits on different characters: ``` array(36) { [0]=> array(2) { [0]=> string(6) "SELECT" [1]=> int(0) } [1]=> array(2) { [0]=> string(1) "p" [1]=> int(7) } [2]=> array(2) { [0]=> string(4) "FROM" [1]=> int(9) } [3]=> array(2) { [0]=> string(40) "Entity\ProductGroupMember" [1]=> int(14) } [4]=> array(2) { [0]=> string(1) "m" [1]=> int(55) } [5]=> array(2) { [0]=> string(1) "I" [1]=> int(57) } [6]=> array(2) { [0]=> string(4) "NNER" [1]=> int(58) } [7]=> array(2) { [0]=> string(2) "JO" [1]=> int(63) } [8]=> array(2) { [0]=> string(1) "I" [1]=> int(65) } [9]=> array(2) { [0]=> string(1) "N" [1]=> int(66) }, ... ``` If I use `setlocale` with `LC_NUMERIC` or comment the line out, or use other languages, everything works fine. Even though the regex and DQL are exactly the same thing.

admin closed this issue

2026-01-22 14:53:45 +01:00

admin commented

2026-01-22 14:53:48 +01:00

@Ocramius commented on GitHub (Dec 18, 2015):

Any pointers as to where the execution path in doctrine/lexer changes (when the locale is changed)?

@Ocramius commented on GitHub (Dec 18, 2015): Any pointers as to where the execution path in doctrine/lexer changes (when the locale is changed)?

admin commented

2026-01-22 14:53:50 +01:00

@billschaller commented on GitHub (Dec 18, 2015):

I just wrote a test (#5565) for the lexer with a bunch of locales and it seems to be fine on Windows with PHP 5.6.13.

@Arany What OS and PHP version are you using?

@billschaller commented on GitHub (Dec 18, 2015): I just wrote a test (#5565) for the lexer with a bunch of locales and it seems to be fine on Windows with PHP 5.6.13. @Arany What OS and PHP version are you using?

admin commented

2026-01-22 14:53:53 +01:00

@AnnaDamm commented on GitHub (Dec 18, 2015):

It is the same exexution path. The Problem appelarently lies in preg_split that takes the same regex and input. The only difference being the setlocale..

I tested it on different machines and now it looks to me like a php-bug. On the machine with 5.5.18 it breaks. On 5.5.30 everything is fine. Only that i do not have Access to the php Installation on the Server so i cannot Upgrade it..

@AnnaDamm commented on GitHub (Dec 18, 2015): It is the same exexution path. The Problem appelarently lies in preg_split that takes the same regex and input. The only difference being the setlocale.. I tested it on different machines and now it looks to me like a php-bug. On the machine with 5.5.18 it breaks. On 5.5.30 everything is fine. Only that i do not have Access to the php Installation on the Server so i cannot Upgrade it..

admin commented

2026-01-22 14:53:55 +01:00

@AnnaDamm commented on GitHub (Dec 18, 2015):

The Server is using CentOS.

@AnnaDamm commented on GitHub (Dec 18, 2015): The Server is using CentOS.

admin commented

2026-01-22 14:53:55 +01:00

@billschaller commented on GitHub (Dec 18, 2015):

@Arany I really don't think there's anything we can do in Doctrine core to mitigate this php bug. If the preg_* functions are behaving badly in the lexer, they're probably behaving badly elsewhere, which could lead to serious issues elsewhere in your app. There were some nasty locale thread safety bugs fixed in 5.5.21.

Your best bet is to get the administrator of the machine to update the PHP installation.

@billschaller commented on GitHub (Dec 18, 2015): @Arany I really don't think there's anything we can do in Doctrine core to mitigate this php bug. If the preg_\* functions are behaving badly in the lexer, they're probably behaving badly elsewhere, which could lead to serious issues elsewhere in your app. There were some nasty locale thread safety bugs fixed in 5.5.21. Your best bet is to get the administrator of the machine to update the PHP installation.

admin commented

2026-01-22 14:53:56 +01:00

@halk commented on GitHub (Feb 13, 2016):

I just had the same error with PHP 5.6.18. Must be related to the host, as all is fine on my mac. The server runs Ubuntu.

@halk commented on GitHub (Feb 13, 2016): I just had the same error with PHP 5.6.18. Must be related to the host, as all is fine on my mac. The server runs Ubuntu.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#4948