Failure / Segmentation fault on Debian lenny and Ubuntu 9.10 while running datagard install/dbinstall

Reading the documentation once more, it seems that dbinstall does everything it should, so the bug would be that it reports a failure at the end of its run.

The same happens with the -a install command: AFAICT it does everything it is supposed to do (but it doesn't create a host), and afterwards, it throws the error mentined above

Does it happen with midgard-core hotfix?

I just tried to reproduce this with a 8.09.6.99 version, but now I get a segfault:

MIDGARD_SETUP: Updating storage for: 'org_openpsa_document'
MIDGARD_SETUP: Successfully created database newdb5
MIDGARD_SETUP: Importing all required xml packages
Segmentation fault
Failed to execute /usr/bin/php /usr/local/share/midgard/setup/php/midgard_datagard.php '-c' 'newdb' -a 'dbinstall'

for unknown reasons, gdb doesn't show me a backtrace for this, unfortunately.

To run with gdb:

gdb php
run /usr/local/share/midgard/setup/php/midgard_datagard.php '-c' 'newdb' -a 'dbinstall'

Can't reproduce on CentOS 5.4 with Midgard 8.09.6.

Can't reproduce on CentOS 5.4 with midgard-core 8.09.6.1.

Can't reproduce on CentOS 5.4 with Midgard 8.09.6.99 (r24577).

This doesn't seem to be a midgard-data/datagard related issue. The original failure probably came from php-midgard or midgard-core. The segfault naturally does. The issue seems to be related to the OS environment as I couldn't see any problems on different platform.

Changing summary and moving this to Midgard Core. Also raising the priority as segfaults are always important to get investigated and fixed. Because I couldn't produce this myself, I set it to critical. If also someone else than flack manages to produce the segfault, make this a blocker I'd say.

Please paste the gdb backtrace if you can. That might be extremely valuable in case this can't be reproduced by others. (Because that wouldn't mean the issue doesn't exist. It would just mean it's something special and its fixing would be only possible with your backtrace information.)

Hi!

Just to add to the confusion: I now tried a different machine with Kubuntu 9.10 and a vanilla 8.09.6.1 compiled from source. There, It stops with the following output:

MIDGARD_SETUP: Installing MidCOM package midcom_admin_settings. Please wait...   already installed

GLib-WARNING **: /build/buildd/glib2.0-2.22.3/glib/gmessages.c:422: could not find handler with id `5' for domain "midgard-core"
aborting...
Aborted
Failed to execute /usr/bin/php /usr/local/share/midgard/setup/php/midgard_datagard.php -a install

The database gets created here as well, but AFAICT only partially.

That GLib-WARNING (#1043) is fixed from r24421 onwards, e.g. in 8.09.6.99.

So it's now reproduced on different platform as well. No segfault there, but it's the same issue.

/usr/bin/php /usr/local/share/midgard/setup/php/midgard_datagard.php -a install exits with something else than 0 there. That's strange if you look at datagard's code because every place where exit is done with something else than 0 there's also something printed to the screen.

Therefore I think php itself exits uncleanly which means php-midgard perhaps does it. Which in turn means midgard-core probably has something which triggers this. Especially since this worked before .6 apparently (e.g. this would perhaps work with midgard-core-8.09.5...).

(In [24589]) Check if given pointer is Midgardconnection instance. Refs #1461

I never guess it correctly between midgard-core and php-midgard. :)

Anyway, great if it works. Can you flack test it now if it works now or not?

I think that commit probably removed the segfault but it is not clear if it fixed the php return status issue.

I just tried with the latest 8.09.6.99 and now the command terminates successfully, so I'm closing as fixed. Thanks for the efforts!