Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Weird RuntimeException when running test suite with --process-isolation #14

Closed
caefer opened this issue Aug 29, 2010 · 13 comments
Closed

Comments

@caefer
Copy link

caefer commented Aug 29, 2010

I get the following error when using the --process-isolation option.

RuntimeException: Parse error: syntax error, unexpected T_CONSTANT_ENCAPSED_STRING

You can reproduce it using this code: http://github.com/caefer/sfPhpUnitDbBootstrapExperimentPlugin
Follow the README.md instruction for setup and perform the included experiments (<2minutes).

@whatthejeff
Copy link
Contributor

This bug exists in PHPUnit 3.5.0RC1 but has been fixed in PHPUnit 3.5.0RC2.

Unfortunately running this test under RC2 will raise another issue. I've documented this issue here: http://github.com/sebastianbergmann/phpunit/issues/issue/17

@meze
Copy link

meze commented Sep 21, 2010

It seems this bug wasn't fixed completely.
I'm running 3.5.0RC2 (under Windows) this code:

namespace Application\TasksBundle\Tests\Model;
class StackTest extends \PHPUnit_Framework_TestCase
{
    public function testPushAndPop() {}
}

Using this command:

phpunit -c tasks ./src\Application\TasksBundle\Tests\Model

(there's just phpunit.xml in tasks with processIsolation="true")

And what i get is:

1) Application\TasksBundle\Tests\Model\StackTest::testPushAndPop
RuntimeException: Parse error: syntax error, unexpected $end in - on line 136

Though, it works fine if i either:

  1. cd tasks and run the command from there (without '-c tasks' argument). OR
  2. Remove 'namespace Application\TasksBundle\Tests\Model;' OR
  3. Set processIsolation="false"

@whatthejeff
Copy link
Contributor

I don't really think this is the same problem. The previous issue happened regardless of namespaces and configuration files and had something to do with single quotes not being escaped properly while globals and constants were being serialized for process isolation.

As for your issue, I can't seem to recreate this with the instructions you've provided. Are you using a bootstrap file or anything that hasn't been posted here?

@whatthejeff
Copy link
Contributor

Meze, maybe your issue is more closely related to http://github.com/sebastianbergmann/phpunit/issues#issue/27. I haven't had the opportunity to test on a Windows system yet.

@whatthejeff
Copy link
Contributor

I finally got a chance to test on Windows 7 (x86-64), but I still couldn't duplicate this bug. Is there any other information you can provide?

@meze
Copy link

meze commented Sep 22, 2010

Yes, i'm using a bootstrap which loads symfony 2,
Here is the code generated by TestCase::run and a piece that opens a process from runJob::php(): http://dl.dropbox.com/u/4488482/issue14.zip
It prints

Array ( [stdout] => Parse error: syntax error, unexpected $end in - on line 140 [stderr] => ) 

Weird, if i remove any line - it doesn't return that parse error

@whatthejeff
Copy link
Contributor

I definitely see a syntax error in the generated code that you've attached. The line that unserializes the UniversalClassLoader has some null terminators in it. Unfortunately, this still isn't enough for me to reproduce the error. If you could attach another zip with the following files I think I could figure out what is going on:

  • C:\www\taskManager\tasks\phpunit.xml
  • C:\www\taskManager\tasks\autoload.php
  • C:\www\taskManager\tasks\TasksKernel.php
  • C:\www\taskManager\src\autoload.php
  • C:\www\taskManager\src\vendor\symfony\src\Symfony\Component\HttpFoundation\UniversalClassLoader.php
  • C:\www\taskManager\src\vendor\propel\runtime\lib\Propel.php
  • C:\www\taskManager\src\vendor\symfony\src\Symfony\Component\HttpKernel\Kernel.php
  • C:\www\taskManager\src\vendor\symfony\src\Symfony\Component\HttpKernel\HttpKernelInterface.php
  • C:\www\taskManager\src\Application\TasksBundle\Tests\Model\TaskTest.php

@meze
Copy link

meze commented Sep 23, 2010

null terminators are ok, this is how php serializes private properties. removing them doesn't help. Attaching files won't help either (because i renamed C:\www\taskManager before i reproduced the error). Guess the bug is in PHP Version 5.3.3 VC6 under windows. Thank you for trying to help.

@whatthejeff
Copy link
Contributor

You are correct that PHP serializes private properties with null terminators. I guess textmate doesn't like literal null characters as it reports that line as a syntax error. I apologize for not looking too much further into it.

I'm actually testing with PHP 5.3.3 under windows. It's just very difficult for anyone to reproduce an error if you're not willing to provide a real working example with source code. The only thing you've provided is PHP files which require a bunch of files that no one else has access to. I'm pretty familiar with the process isolation code and I'd really like to help track down this bug but there's not much I can do if you're not willing to provide any code. Maybe sebastian will be able to take a better guess at it than I can.

@meze
Copy link

meze commented Sep 23, 2010

I tried to provide as less code as possible. I have removed C:\www\taskManager directory temporarily and the error is still can be reproduced. I hope you haven't made any changes in 'output' file, because when i remove/change a line, the error mysteriously disappears.

@meze
Copy link

meze commented Sep 23, 2010

It's not a phpunit related bug.
I've posted a bug report on php.net (http://bugs.php.net/bug.php?id=52911)
let's wait for their answer ;)

@Bouke
Copy link
Contributor

Bouke commented Oct 8, 2010

While we wait for a fix in a future version of PHP, I've created a workaround using the comment on the bug page. I proposed a workaround in http://github.com/sebastianbergmann/phpunit/pull/41.

@sebastianbergmann
Copy link
Owner

Pulled the fix from Bourke.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants