archiving custom functions
Hello all, I was trying to archive custom functions (functions done with the macros as detailed in the tutorial, archiving also as in the tutorial). Archiving works fine, viewing the archives with viewgar -d gives me a complete output, without the -d switch viewgar complains about a non-existent function (logically!). When I try to read them in, however, I get a segmentation fault. Therefore my question: do I have to do anything special to make this work, or could it be a bug in the compiler? (which I cannot change, unfortunatly) Thanks ___________________________________________________________ Neu: WEB.DE De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: https://produkte.web.de/go/demail02
Hello all,
I was trying to archive custom functions (functions done with the macros as detailed in the tutorial, archiving also as in the tutorial). Archiving works fine, viewing the archives with viewgar -d gives me a complete output, without the -d switch viewgar complains about a non-existent function (logically!).
When I try to read them in, however, I get a segmentation fault. Therefore my question: do I have to do anything special to make this work, or could it be a bug in the compiler? (which I cannot change, unfortunatly)
Thanks
I tried now on another system with a newer compiler, and also get a segmentation fault, so it seems it's not a compiler bug. I'm using the newest CLN and GiNaC, self-compiled and also openSuSE packages, both don't work. Looking through the source code, unarchiving a function should also work with custom functions, since they search for the function serial by name. My guess would be that the unarchiving code mistakes my function for a symbol which isn't passed, tries to create it and somehow segfaults there, but this is only an uninformed guess, I haven't dug that deep into the source code. ___________________________________________________________ WEB.DE DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 für nur 19,99 €/mtl.!* http://produkte.web.de/go/DSL_Doppel_Flatrate/2
Hello all,
I was trying to archive custom functions (functions done with the macros as detailed in the tutorial, archiving also as in the tutorial). Archiving works fine, viewing the archives with viewgar -d gives me a complete output, without the -d switch viewgar complains about a non-existent function (logically!).
When I try to read them in, however, I get a segmentation fault. Therefore my question: do I have to do anything special to make this work, or could it be a bug in the compiler? (which I cannot change, unfortunatly)
Thanks
I tried now on another system with a newer compiler, and also get a segmentation fault, so it seems it's not a compiler bug. I'm using the newest CLN and GiNaC, self-compiled and also openSuSE packages, both don't work. Looking through the source code, unarchiving a function should also work with custom functions, since they search for the function serial by name. My guess would be that the unarchiving code mistakes my function for a symbol which isn't passed, tries to create it and somehow segfaults there, but this is only an uninformed guess, I haven't dug that deep into the source code.
After doing a gdb backtrace, I see that it crashes on l. 310 of ex.cpp, which is const ex & tmpex = other.eval(1); and it seems that GiNaC goes into an infinite loop trying to construct an expression from basic. backtrace: #0 GiNaC::ex::construct_from_basic (other=@0x6b4890) at ex.cpp:293 #1 0x0000000000416509 in GiNaC::symbol::eval (this=0x6b4890, level=1) at /usr/local/include/ginac/ex.h:255 #2 GiNaC::ex::construct_from_basic (other=@0x6b4890) at ex.cpp:293 #3 0x0000000000416509 in GiNaC::symbol::eval (this=0x6b4890, level=1) at /usr/local/include/ginac/ex.h:255 #4 GiNaC::ex::construct_from_basic (other=@0x6b4890) at ex.cpp:293 #5 0x0000000000416509 in GiNaC::symbol::eval (this=0x6b4890, level=1) at /usr/local/include/ginac/ex.h:255 ... (at least 10k of those lines) I am calling hold() in the eval() function of my custom function, so in principle this should work, no? ___________________________________________________________ WEB.DE DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 für nur 19,99 €/mtl.!* http://produkte.web.de/go/DSL_Doppel_Flatrate/2
Hello,
After doing a gdb backtrace, I see that it crashes on l. 310 of ex.cpp, which is
const ex & tmpex = other.eval(1);
This sounds like a missing hold() in a user-defined function, but might be a GiNaC bug as well.
and it seems that GiNaC goes into an infinite loop trying to construct an expression from basic.
backtrace:
#0 GiNaC::ex::construct_from_basic (other=@0x6b4890) at ex.cpp:293 #1 0x0000000000416509 in GiNaC::symbol::eval (this=0x6b4890, level=1) at /usr/local/include/ginac/ex.h:255 #2 GiNaC::ex::construct_from_basic (other=@0x6b4890) at ex.cpp:293 #3 0x0000000000416509 in GiNaC::symbol::eval (this=0x6b4890, level=1) at /usr/local/include/ginac/ex.h:255 #4 GiNaC::ex::construct_from_basic (other=@0x6b4890) at ex.cpp:293 #5 0x0000000000416509 in GiNaC::symbol::eval (this=0x6b4890, level=1) at /usr/local/include/ginac/ex.h:255 ... (at least 10k of those lines)
The backtrace sort of confirms my idea, but we need the outermost frames to find out what's actually going on. gdb ./that/program [wait until it segfaults] bt -16 and post the output here. Best regards, Alexei
Hello,
After doing a gdb backtrace, I see that it crashes on l. 310 of ex.cpp, which is
const ex & tmpex = other.eval(1);
This sounds like a missing hold() in a user-defined function, but might be a GiNaC bug as well.
This possibility is mentioned in the manual, yes, but I have hold() in my function. In fact, in constructing a minimal testcase I noticed that it is not the archiving of the function which fails but the archiving of a realsymbol. The testcase is attached below. Sorry for producing unrelated noise!
and it seems that GiNaC goes into an infinite loop trying to construct an expression from basic.
backtrace:
#0 GiNaC::ex::construct_from_basic (other=@0x6b4890) at ex.cpp:293 #1 0x0000000000416509 in GiNaC::symbol::eval (this=0x6b4890, level=1) at /usr/local/include/ginac/ex.h:255 #2 GiNaC::ex::construct_from_basic (other=@0x6b4890) at ex.cpp:293 #3 0x0000000000416509 in GiNaC::symbol::eval (this=0x6b4890, level=1) at /usr/local/include/ginac/ex.h:255 #4 GiNaC::ex::construct_from_basic (other=@0x6b4890) at ex.cpp:293 #5 0x0000000000416509 in GiNaC::symbol::eval (this=0x6b4890, level=1) at /usr/local/include/ginac/ex.h:255 ... (at least 10k of those lines)
The backtrace sort of confirms my idea, but we need the outermost frames to find out what's actually going on.
gdb ./that/program
[wait until it segfaults]
bt -16
and post the output here.
bt -16 gives #392953 0x0000000000409449 in ex (other=<value optimized out>, this=<value optimized out>) at /usr/local/include/ginac/ex.h:255 #392954 GiNaC::symbol::eval (other=<value optimized out>, this=<value optimized out>) at /usr/local/include/ginac/symbol.h:49 #392955 0x00007ffff79adb66 in GiNaC::ex::construct_from_basic (other=...) at ex.cpp:310 #392956 0x0000000000409449 in ex (other=<value optimized out>, this=<value optimized out>) at /usr/local/include/ginac/ex.h:255 #392957 GiNaC::symbol::eval (other=<value optimized out>, this=<value optimized out>) at /usr/local/include/ginac/symbol.h:49 #392958 0x00007ffff79adb66 in GiNaC::ex::construct_from_basic (other=...) at ex.cpp:310 #392959 0x0000000000409449 in ex (other=<value optimized out>, this=<value optimized out>) at /usr/local/include/ginac/ex.h:255 #392960 GiNaC::symbol::eval (other=<value optimized out>, this=<value optimized out>) at /usr/local/include/ginac/symbol.h:49 #392961 0x00007ffff79adb66 in GiNaC::ex::construct_from_basic (other=...) at ex.cpp:310 #392962 0x0000000000409449 in ex (other=<value optimized out>, this=<value optimized out>) at /usr/local/include/ginac/ex.h:255 #392963 GiNaC::symbol::eval (other=<value optimized out>, this=<value optimized out>) at /usr/local/include/ginac/symbol.h:49 #392964 0x00007ffff79adb66 in GiNaC::ex::construct_from_basic (other=...) at ex.cpp:310 #392965 0x00007ffff797a3a4 in ex (other=<value optimized out>, this=<value optimized out>) at ex.h:255 #392966 GiNaC::archive_node::unarchive (other=<value optimized out>, this=<value optimized out>) at archive.cpp:543 #392967 0x00007ffff797a9f1 in GiNaC::archive::unarchive_ex (this=0x7fffffffe060, sym_lst=<value optimized out>, index=<value optimized out>) at archive.cpp:105 #392968 0x0000000000408937 in main () at test.cpp:33
Best regards, Alexei
Thanks a lot for helping! GiNaC is just great, uses way less memory than Mathematica and works just fine for me, except that archiving thing. The testcase: #include <iostream> #include <fstream> #include <stdexcept> using namespace std; #include <ginac/ginac.h> using namespace GiNaC; int main() { archive aro, ari; realsymbol r("r"); ex test, test2; test = r; cerr << "writing archive\n"; ofstream aus("test.gar"); aro.archive_ex(test, "test"); aus << aro; aus.close(); cerr << "done writing archive\n"; cerr << "reading archive\n"; ifstream ein("test.gar"); ein >> ari; ein.close(); cerr << "done reading archive\n"; lst symlst; symlst = r; cerr << "unarchiving\n"; try { test2 = ari.unarchive_ex(symlst); } catch (std::exception &e) { cerr << e.what() << std::endl; } cerr << "recovered expression\n"; return 0; } ___________________________________________________________ GRATIS: Spider-Man 1-3 sowie 300 weitere Videos! Jetzt kostenlose Movie-FLAT freischalten! http://movieflat.web.de
Hi,
This possibility is mentioned in the manual, yes, but I have hold() in my function. In fact, in constructing a minimal testcase I noticed that it is not the archiving of the function which fails but the archiving of a realsymbol. The testcase is attached below.
Thanks for pinning this down. I'm working on a fix. Best regards, Alexei
Thanks for the fix! Regards, Markus
Hi,
This possibility is mentioned in the manual, yes, but I have hold() in my function. In fact, in constructing a minimal testcase I noticed that it is not the archiving of the function which fails but the archiving of a realsymbol. The testcase is attached below.
Thanks for pinning this down. I'm working on a fix.
Best regards, Alexei
WEB.DE DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit gratis Notebook-Flat! http://produkte.web.de/go/DSL_Doppel_Flatrate/2
participants (3)
-
"Markus Fröb"
-
Alexei Sheplyakov
-
grey_earl＠web.de