Segmentation fault

[cdeval]

Salut Bernard,

je finalise ma mise à jour et en testant sous linux 32, j'ai un problème de plantage de OOo.
je te consulte avant de me lancer dans des recherches plus poussées avec recompil de giac en mode debug par exemple.
Mon plantage se produit quand, dans OOo, je compile une fonction, par exemple :

Code : Tout sélectionner

test(x):={1}

et que je configure ensuite le moteur CAS en passant l'instruction :

Code : Tout sélectionner

cas_setup(0,0,0,1,0,1e-10,10,[1,50,0,25],0,1,0)

je récupère cela :

Code : Tout sélectionner

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb4da4700 (LWP 6549)]
0xb727ec98 in std::basic_ios<char, std::char_traits<char> >::operator void* ()
   from /opt/openoffice.org3/program/../basis-link/ure-link/lib/libstdc++.so.6
(gdb) bt
#0  0xb727ec98 in std::basic_ios<char, std::char_traits<char> >::operator void* ()
   from /opt/openoffice.org3/program/../basis-link/ure-link/lib/libstdc++.so.6
#1  0xaaee93e6 in giac::cas_setup ()
   from /home/chris/.openoffice.org/3/user/uno_packages/cache/uno_packages/xStsnY_/CmathOOoCAS.oxt/Linux_x86/libgiac.so.0
#2  0xaaeeaa8d in giac::_cas_setup ()
   from /home/chris/.openoffice.org/3/user/uno_packages/cache/uno_packages/xStsnY_/CmathOOoCAS.oxt/Linux_x86/libgiac.so.0
#3  0xaaf5b7a6 in giac::unary_function_eval::operator() ()
   from /home/chris/.openoffice.org/3/user/uno_packages/cache/uno_packages/xStsnY_/CmathOOoCAS.oxt/Linux_x86/libgiac.so.0
#4  0xaabc7e1b in giac::symbolic::eval ()
   from /home/chris/.openoffice.org/3/user/uno_packages/cache/uno_packages/xStsnY_/CmathOOoCAS.oxt/Linux_x86/libgiac.so.0
#5  0xaafcdbff in giac::gen::in_eval ()
   from /home/chris/.openoffice.org/3/user/uno_packages/cache/uno_packages/xStsnY_/CmathOOoCAS.oxt/Linux_x86/libgiac.so.0
#6  0xaafcd644 in giac::gen::eval ()
   from /home/chris/.openoffice.org/3/user/uno_packages/cache/uno_packages/xStsnY_/CmathOOoCAS.oxt/Linux_x86/libgiac.so.0
#7  0xab7192c9 in my_sc_impl::CASImpl::cas ()
   from /home/chris/.openoffice.org/3/user/uno_packages/cache/uno_packages/xStsnY_/CmathOOoCAS.oxt/Linux_x86/CmathOOoCAS.uno.so
#8  0xb3950828 in ?? () from /opt/openoffice.org/ure/lib/libgcc3_uno.so
#9  0xb3950b3a in ?? () from /opt/openoffice.org/ure/lib/libgcc3_uno.so
#10 0xb3950ed9 in ?? () from /opt/openoffice.org/ure/lib/libgcc3_uno.so
#11 0xacd1f89d in ?? () from /opt/openoffice.org/ure/lib/reflection.uno.so
#12 0xad5e1518 in ?? () from /opt/openoffice.org3/program/../basis-link/program/libscli.so
etc...

Si je fais la même manipulation dans un terminal "giac", le problème n'apparaît pas
Si dans OOo, je ne compile pas de fonction avant le cas_setup, pas de problème
Si dans OOo, je compile une fonction sans faire de cas_setup derrière, pas de problème
Je n'ai pas ce problème avec linux 64
je pense que j'ai le même problème sous windows 32 (plantage mais pas de gdb sous win pour vérifier)

Y aurait-il un lien avec la gestion du flux d'erreur (logptr) introduit dans mon code qui me sert à compiler sous OOo et qui serait mal supporté par cas_setup ?

pour info ci dessous mon code qui appelle cas_setup :

Code : Tout sélectionner

Any CASImpl::cas( Any const & contenu )
    throw (RuntimeException)
// fonction qui ne fait qu'évaluer le contenu d'une cellule
// appelée aussi par writer
{
	if (!contenu.hasValue()) return syntaxErreur();
	gen e;
	giac::context * contextptr=0;
	e=Cellule2Gen(contenu);	
	giac::child_id=1; // certaines fonctions giac (comme laplace, cas_setup...) nécessite ce contexte
	try {
		e=giac::eval(e,contextptr);
	} catch (std::runtime_error & erreur){
		// english only with Giac
		return makeAny(OUString::createFromAscii(erreur.what()));
	}
	return Gen2any(e);
}

et celui qui sert à compiler :

Code : Tout sélectionner

Sequence< Sequence< Any > > CASImpl::casWithLog( Any const & contenu )
    throw (RuntimeException)
// fonction créée pour les instruction giac comportant une compilation de fonction
// renvoie un vecteur contenant :
// 1) le résultat
// 2) le flux d'erreurs
// 3) le numéro de la ligne ou a lieu la 1ère erreur
// 4) le mot qui est source de l'erreur
{
	if (!contenu.hasValue()) return syntaxErreurMatrix();
	giac::context * contextptr=0;
	// ne pas passer par Cellule2Gen car le flux d'erreur n'est pas géré et cela
	// fait planter OOo
	// e=Cellule2Gen(contenu);	
	giac::child_id=1; // certaines fonctions giac (comme laplace, cas_setup...) nécessite ce contexte
	OUString chaine;
	contenu >>= chaine;
	ostringstream oss(ostringstream::out);
	oss.str("");
	logptr(&oss,contextptr);
	OString aOString = OUStringToOString (chaine,RTL_TEXTENCODING_UTF8);
	gen e(string(aOString),contextptr);
	Sequence< Sequence< Any > > sortie;
	try {
		e=giac::eval(e,contextptr);
	} catch (std::runtime_error & erreur){
		Sequence< Any >	solList1D(1);
		Sequence< Sequence< Any > > solList2D(1);
		solList1D[0]=makeAny(OUString::createFromAscii(erreur.what()));
		solList2D[0]=solList1D;
		sortie=solList2D;
		return sortie;
	}
	Sequence< Any >	solList1D(4);
	Sequence< Sequence< Any > > solList2D(1);
	// renvoie le flux d'erreur dans le 1er élément
	const sal_Char * flux;
	flux=oss.str().c_str();
	solList1D[0]=makeAny(OUString::createFromAscii(flux));
	// renvoie le résultat évalué dans le second
	solList1D[1]=Gen2any(e);
	// renvoie le n° de ligne de l'erreur
	sal_Int32 errorLine(giac::first_error_line(contextptr));
	solList1D[2]=makeAny(OUString::valueOf(errorLine));
	// et le mot à l'origine de l'erreur
	const sal_Char * tokenName(giac::error_token_name(contextptr).c_str());
	solList1D[3]=makeAny(OUString::createFromAscii(tokenName));

	solList2D[0]=solList1D;
	sortie=solList2D;
	return sortie;
}

Si ça t'inspire....

[parisse]

Je ne vois pas (en-dehors du fait que cas_setup fait une sortie sur le flux *logptr(contextptr) lorsque debug_infolevel>0), il va falloir que tu utilises une libgiac.so compilee avec -g pour voir ou se situe exactement le segfault. Ou bien tu reconfigures par un appel direct en C++ par exemple complex_mode(true,contextptr); (cf. global.h pour les noms des fonctions).

[cdeval]

sous linux 32, j'ai simplement ajouté :

Code : Tout sélectionner

   ostringstream oss(ostringstream::out);
   oss.str("");
   logptr(&oss,contextptr);

dans mon code qui appelle cas_setup et ça a suffit pour ne plus planter !
je vais tester sous win32 plus tard dans la soirée.

[parisse]

ah oui, c'est quand tu crées ton flux chaine, puis *logptr(contextptr) pointe dessus, mais si tu ne remets pas logptr(0,contextptr) après tu risques un segfault à tout moment, parce que le flux chaine a été détruit mais le pointeur pointe toujours dessus!

[cdeval]

OK, je me doutais d'un truc de ce genre. OOo est plutôt chatouilleux quand on ne fait pas les choses dans les règles.
En tout cas, en refermant le flux correctement, je n'ai plus de problème, ni avec linux32, ni avec win32 .
Même sans gérer le flux avec cas_setup, ça ne plante plus. C'était bien le pointeur qui pointait dans le vide.

Mais comme tu m'as dit qu'il pouvait y avoir une sortie de flux avec cas_setup, je vais quand même laisser mon logptr(&oss,contextptr); dans mon instruction cas() (avec logptr(0,contextptr) après bien sûr !)

Une petite question : à part une compilation ou la commande cas_setup, y a-t-il d'autres commandes giac susceptibles de provoquer une sortie de flux ? Parce que dans les autres instructions que j'ai intégrées dans OOo, je ne le gère jamais et cela n'a jamais planté.

merci pour ton aide.

[parisse]

oui, il y en a d'autres, mais c'est rare si debug_infolevel n'est pas mis à une valeur non nulle. Ceci dit tant que le pointeur est 0 (ou à une valeur valide) pas de problèmes, c'est s'il est invalide que ca peut poser problèmes, je ne comprends quand même pas pourquoi tu as eu ce plantage si debug_infolevel est à 0.

[cdeval]

oui, je n'ai pas touché à debug_infolevel pourtant.
Mais d'après la trace, comme le problème semble venir de "ure-link/lib/libstdc++.so.6" une librairie fournie par OOo et appelée par cas_setup(), peut-être qu'il y a une gestion du flux dans cette librairie...
Ce phénomène dépasse mes faibles compétences en C++ !

[parisse]

je ne vois pas non plus, sinon qu'il faut que tu penses toujours à remettre logptr(0,contextptr) avant destruction du flux utilisé.