View Issue Details

IDProjectCategoryView StatusLast Update
0025390mantisbttoolspublic2021-01-01 19:25
Reporterdregad Assigned Todregad  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Fixed in Version2.20.0 
Summary0025390: Travis CI builds fail for PHP 7.3
Description

Starting with https://travis-ci.org/mantisbt/mantisbt/builds/474910229, our PHP 7.3 builds started failing due to a Segmentation Fault when attempting to access the PHP built-in webserver via curl. All other PHP versions work just fine, and it used to work for PHP 7.3 too before (see the last successful run https://travis-ci.org/mantisbt/mantisbt/builds/474609460 for example).

Example error from https://travis-ci.org/mantisbt/mantisbt/jobs/474910237#L524

curl: (52) Empty reply from server
./scripts/travis_before_script.sh: line 136: 4012 Segmentation fault (core dumped) $myphp -S $HOSTNAME:$PORT &> /dev/null
The command "./scripts/travis_before_script.sh" failed and exited with 52 during .

All the builds fail at the same point in the before_script (although the segfault error is not always present in the log file). We have not changed anything in the script, or in the .travis.yml,

Additional Information

This issue has been reported to TravisCI support on 07-Jan-2019 (ref. Travis CI: [2542] - PHP 7.3 builds fail with segmentation fault)

TagsTravisCI

Activities

dregad

dregad

2019-01-28 03:24

developer   ~0061310

I tried to find out what could be causing the problem, here is the branch I used for testing https://github.com/dregad/mantisbt/commits/travis-test2.

This commit https://github.com/dregad/mantisbt/commit/b2f671f57c0b88e2fbe07a9a2b1bcd41c9650288 triggered a successful build (https://travis-ci.org/dregad/mantisbt/jobs/476936902), so it would imply that the segfault is caused by something within the php.ini file.

dregad

dregad

2019-01-28 03:25

developer   ~0061311

Last edited: 2019-01-28 03:25

Feedback from TravisCI support (Jan 17, 17:28 EST) :


Hey Damien,

Thanks for reaching out and I'm terribly sorry for the delay of my reply.

I generated a diff between your last successful build (left) and your first failing one (red) that you can inspect here: https://www.diffchecker.com/fV8ZmbPY.

One thing I notice is that the PHP 7.3 runtime's date changed in between i.e.

success: PHP 7.3.0 (cli) (built: Dec 28 2018 17:41:08) ( ZTS )
vs
failure: PHP 7.3.0 (cli) (built: Jan 3 2019 03:12:37) ( ZTS )

I also see that the new runtime includes Xdebug v2.7.0beta2-dev which wasn't the case in the green build.

Is it possible that it's a regression in the runtime?

Please let me know what you think.

Thanks!

-- Dominic.

--
Dominic Jodoin

dregad

dregad

2019-01-28 03:27

developer   ~0061312

My response (25 Jan 2019) :


Hello Dominic,

Thanks for getting back to me, and apologies for not replying sooner, I've been busy.

I'm not sure whether the PHP build or xdebug is the root cause or not, but it is indeed a possibility. I've created a new test branch to re-run both commits against the same build, in the hope of providing you with a cleaner base to work with to find the root cause for the crash. Unfortunately I'm not getting the segfault anymore (which means that at least our installer is starting properly now), but the job still fails.

Analyzing the error, it would appear that the database is not properly initialized, for a reason that I am not able to determine for now.

The difference between the 2 jobs is simply that the successful one starts with a -c php.ini parameter, so again my guess is that the something in the default php.ini is causing this.

dregad

dregad

2019-01-28 04:34

developer   ~0061313

More tests: it would appear that xdebug is causing the issue. Disabling it as documented in https://github.com/travis-ci/travis-ci/issues/1697#issuecomment-29542251 allows the PHP 7.3 builds to complete successfuly.

As I didn't received any feedback from TravisCI support yet, I'm going to apply this to our master branch as a workaround. Hopefully they will eventually find and fix the root cause, at which point we can revert the workaround.

dregad

dregad

2019-02-09 06:33

developer   ~0061460

Last edited: 2019-02-09 06:34

I received feedback from TravisCI support asking me to test again, and it would appear that the problem has been resolved on their end, as all builds were successful without of disabling xdebug :

Therefore I'm reverting the workaround MantisBT master cde055fa

Related Changesets

MantisBT: master cde055fa

2019-01-27 23:36

dregad


Details Diff
Travis: disable xdebug for PHP 7.3 builds

This is a temporary workaround, to allow our builds to succeed until
TravisCI is able to fix the root cause.

Fixes 0025390
Affected Issues
0025390
mod - scripts/travis_before_script.sh Diff File

MantisBT: master b91a52e2

2019-02-08 23:11

dregad


Details Diff
Revert "Travis: disable xdebug for PHP 7.3 builds"

Following feedback from Travis support, it would appear that they
somehow fixed the problem that caused the builds to fail, although I
have no information about what they did.

Following a successful test build

This reverts commit cde055fab5e6227f8818c749d89c12e0cb71a696.

Fixes 0025390
Affected Issues
0025390
mod - scripts/travis_before_script.sh Diff File