[Bug] Backpack in a subdomain (V7)

[cdo9]

Hello,

This setup (#887) was working correctly with Backpack v6, but since upgrading to Backpack v7 I’m hitting a hard PHP segfault (exit 139) during request handling. (On all my routes)

What I’ve isolated so far:

• The crash happens during Kernel::handle() (before controllers, before my own middleware).
• /up health route also segfaults.
• If I disable auto-discovery for Backpack CRUD/Basset, the app works again.
• Rolling back to Backpack v6 fixes the issue immediately.
• Removing my multisite middleware, route groups, cache, locale, etc. does not change the behavior.

I already had multisite support working with your help back in the v6 days, so I’m wondering if something changed in v7 (route registration, URL generation, auth/guard setup, etc.) that could explain this regression?

Happy to provide more details if needed, thanks in advance for your help

[backpack-ai-bot]

CrawlChat Answer:

I understand this is a critical issue - PHP segfaults during Kernel::handle() after upgrading to Backpack v7, specifically affecting subdomain/multisite setups. Unfortunately, this specific bug scenario is not documented in the available Backpack resources.

However, I found relevant context about v7 changes that might help:

What Changed in v7:

Backpack v7 made significant updates to Basset (the asset manager) - you can disable auto-discovery as a temporary workaround since you've confirmed it prevents the segfault.

Suggested Next Steps:

1. Check if this is related to Basset v2's new behavior - the upgrade from Basset v1 to v2 changed some defaults
2. Clear and republish Basset assets: php artisan basset:clear
3. Check Laravel logs for segfault stack traces to identify the specific component crashing

Best Course of Action:

Since this worked in v6 and you've isolated it to auto-discovery, I recommend reaching out to the Backpack support team or opening a GitHub issue on Laravel-Backpack/CRUD with:

• Your php artisan backpack:version output
• The segfault stack trace from your system logs
• Your multisite middleware setup

This appears to be a regression that the maintainers would want to investigate directly, especially since you've already done excellent troubleshooting isolating it to the auto-discovery feature.

ℹ️ Please note our AI Bot does not reply to follow-ups, this will be the only AI answer in this thread. If the AI helped you find the answer, please mark it as answered or write details below so it can learn. Then close the conversation. If not, please give more information for when a human reads this. ℹ️

Relevant sources:

Backpack v7 - The Admin Panel Framework You'll Love :: Backpack for Laravel
HUGE DISCOUNTS - Let's Celebrate Backpack v7 Beta! Hurry Up! :: Backpack for Laravel
Progress Report: July 2025 :: Backpack for Laravel
Backpack v7 is officially RELEASED :: Backpack for Laravel
v7 bug, maybe
[Bug] Field Address Google with Javascript error
Release Notes :: 7.x Docs :: Backpack for Laravel
CRUD List isn't displaying records
Upgrade Guide :: 7.x Docs :: Backpack for Laravel
Black Week DISCOUNTS - Hurry Up! :: Backpack for Laravel

[pxpm]

Hey @cdo9 thanks for the report.

Any error you can give me? either from laravel.log or from server/php logs?

Cheers

[cdo9]

Hey @pxpm , sorry for the late response.

Here are the server logs :

2026-01-29 09:12:38,103 WARN exited: php (exit status 139; not expected)

2026-01-29 09:12:39,107 INFO spawned: 'php' with pid 1655

2026-01-29 09:12:40,110 INFO success: php entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

PHP Warning:  JIT is incompatible with third party extensions that override zend_execute_ex(). JIT disabled. in Unknown on line 0

INFO  Server running on [http://0.0.0.0:80].  

Press Ctrl+C to stop the server

Edit1: There is no Laravel logs, Basset is also failing to cache on composer update : Failed to cache: /var/www/html/path_to_file

Edit2: I'm using Laravel Sail on Mac OS

Thanks you