Hi!
I am glad!
It is actually more a workaround until what breaks in Fax Pro for migrated setups gets fixed. Did anyone open a ticket for this?
I am still in formation (it’s actually a presentation and not really a formation) with a security firm so I can’t check if a ticket exists right now and open one if it does not.
@sysdg, if that doesn’t work let me know…
(and if it does too please 
)
Have a nice day!
Nick
Hi @sysdg!
If removing faxpro doesn’t work for you please only apply the modifications I put in this (edited) post:
This should only give a few lines of information… If it gives more send me a PM with the first 20 so that I have an idea of what it is trying to output…
I am expecting that your problem will be the same as @aj2 but will wait until I hear back from you to create the ticket so that we know if we are dealing with one or two problems.
Since FAX Pro is a commercial module it’s impossible to look at its source code (because all commercial modules source code is obfuscated) so the only thing we can do is identify which module is to blame and create a ticket so that the FreePBX devs can fix it.
There is a possibility that the migration tool that you ran is to blame, that it might not have initialized a something Fax Pro is looking for but I don’t think a problem in Fax Pro should not break UCP, the worst it should do is make Fax Pro functionalities unavailable in UCP…
Good luck and have a nice day!
Nick
Hi nick, No we did not open a ticket. Not sure if related or helpful, but in the same way the FaxPro module did not appear in the web interface > Admin > Module Admin, when earlier in the trouble shooting process we tried to remove the Contacts Manager it prompted to first remove the restapps module, but we could not see that on the module admin page.
Hi @aj2!
No problem… I will open one as soon as I get confirmation from sysdg whether he has the same problem or not…
Thank you for the additional input!
Have a nice day!
Nick
This is not entirely true. A stack trace will still return the file and line number. Which would be a requirement for any ticket for such an issue.
You can see the correct smaller stack trace by removing the try catch in the sections you discussed earlier.
Thanks to all!
That worked. Removing FaxPro fixes UCP
After uninstalling the faxpro module I have tried to reinstall it and UCP is still working correctly
Faxpro version is 13.0.38.7
I had the same strange behavior with Symphony, that was not working since we migrated from Elastix untill we reinstalled it
Hi!
Good idea!
When you install a module it adds the table(s) it needs and, if needed, populates (ie add needed entries) then.
It looks like the migration script does not populate/initialize Fax Pro table)(s) as it should for the current version of the Fax Pro module.
I have asked people to reinstall modules in the past but didn’t think of it this time because I could not analyze the code and the error message was not something as clear cut as a missing database column or something like that.
I will create a ticket later today (I now have to get ready for work).
Have a nice day!
Nick
Please include the line number and file of the error.
Hi Andrew!
I over simplified things, my point was that there was not much I could do besides identifying which module was involved in the crash.
I knew a stack trace was required, this is why I had them replace $e->getMessage() with $e->getTraceAsString().
This is what doing this gave us earlier, this is why I suggested they remove Fax Pro to see if UCP would stop crashing.
There was an error trying to load UCP:
#0 /var/www/html/admin/modules/faxpro/ucp/Faxpro.class.php(27): Whoops\Run->handleError(2, 'Division by zer...', '/var/www/html/a...', 27, Array)
#1 /var/www/html/admin/modules/ucp/htdocs/includes/Module_Helpers.class.php(119): UCP\Modules\Faxpro->__construct(Object(UCP\Modules))
#2 /var/www/html/admin/modules/ucp/htdocs/includes/Module_Helpers.class.php(33): UCP\Module_Helpers->autoload('Faxpro')
#3 /var/www/html/admin/modules/ucp/htdocs/includes/Modules.class.php(84): UCP\Module_Helpers->__get('Faxpro')
#4 /var/www/html/admin/modules/ucp/htdocs/includes/Modules.class.php(105): UCP\Modules->moduleHasMethod('Faxpro', 'getMenuItems')
#5 /var/www/html/admin/modules/ucp/htdocs/includes/Modules.class.php(163): UCP\Modules->getModulesByMethod('getMenuItems')
#6 /var/www/html/admin/modules/ucp/htdocs/index.php(106): UCP\Modules->getActiveModules()
#7 {main}
(I reformated it to make it more readable…)
re: UCP error division by zero - #12 by Marbled
Now from what I have read Faxpro.class.php at line 27 is possibly not the line where there is a division by zero but the first line of the method (constructor?) where an operation that results in a division by zero is.
re: The first comment of PHP: Exception::getTraceAsString - Manual
There is apparently another way to get a stack trace with more details but it would have involved having to code it (or find some helper function in FreePBX source code that does it).
Would removing the try catch completely gave us more information? Unfortunately, it is too late for that now…
edit: I don’t think it would… Now that I had reformated the stack trace and had the time to look at this further it looks like line 27 is actually error handling code most likely called from another try-catch…
Unless that method/function is extremely long and with multiple divide operations (or something that would result in a divide) I am pretty sure that if this was one of the application I maintain I would have enough information to go on with what @aj2 provided…
I also have a feeling that this is code that was modified after the migration script was published so comparing what was there at the time to what is currently there would most likely severely limit the number of “suspects” .
Honestly, right now and considering we had two people in close succession report this problem, I would not be surprised if breaks for everyone who migrates right now. This might actually be easy to replicate in-house…
Andrew, my main job is programming and I have been doing this for over 20 years now…
I have a more important technical/network admin like background than most programmers but I am still a programmer and I know what is needed in order to track down a problem (ie a stack trace).
I will include what I posted in this ticket, hopefully that will be enough to track down the problem as far as Fax Pro is concerned.
Problem is, while I think Fax pro and UCP should be more tolerant to a situation like this and not make UCP entirely unusable like it did for @aj2 and @sysdg, that it should only warn that there is a problem, it sounds to me like this is a problem with the migration program/script, not with Fax Pro itself.
Something seems not to be initialized properly during the migration.
When the migration program/script was released things were most likely OK as far as Fax Pro was concerned but something was most likely added to Fax Pro which is causing problems now…
When I open that ticket do you want me to open it under (what component, etc…)? I am not quite sure since it was UCP that was crashing but because of code in Fax Pro but that code was most likely crashing because the migration script/program did not initialize something correctly…
Have a nice day!
Nick
I just would like to kno whow to reproduce this issue.
I’ve got a server made from Elastix 2.5 server and i’m running on Freepbx 14.
Until there, i can connect on UCP without any problem.
I can use Fax widget too. I have no error,