opencog / opencog

A framework for integrated Artificial Intelligence & Artificial General Intelligence (AGI)

Home Page:http://wiki.opencog.org/w/Development

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Test if AnaphoraTest passes when not using Pymalloc

ferrouswheel opened this issue · comments

commented

Discovered that building with Python3 will use libpython3m.so by default: opencog/atomspace#2270 - one thing to test is whether swapping to normal malloc (i.e. linking against libpython3.so) has any impact on the AnaphoraTest failure "too many root sets" mentioned in #3529 - the Boehm GC may not like whatever Python is doing to maintain it's own memory management.

commented

Looks like an interesting read.

(I edited your comment to remove the spam)

BoehmGC is "conservative" it knows which memory it is supposed to be managing, and which belongs to someone else. It knows which is which because it knows who called malloc. Maybe the failure might be due to fragmentation: maybe it tries to keep each chunk of RAM that it is supposed to be managing in it's own "root set" and by interleaving too many guile mallocs with other mallocs might overflow something. Although this does not quite make sense, because the C++ code is going hog-wild making tiny mallocs, which should cause tremendous fragmentation, and that is not causing any problems...

@TheScott463 when you reply with your verizon phone, verizon attaches a large quantity of junk to your messages, and that junk gets recorded into github. making it hard-to-read. That's the "spam" that Joel refers to. (take a look at the web page).

@TheScott463 the "too many root sets" error message is printed by BoehmGC and not by glibc nor by python. This issue is not debugging malloc, but understanding why "too many root sets" is being printed.

"BoehmGC is "conservative" "

But python is "aggressive" with malloc and stacks and it "overflows" intentionally at times. Perhaps, python is chewing through "root sets" on accident.

Then again, I'm guessing and probably don't get the real problem yet.

Hmm. Well, writing to memory that doesn't belong to you is famously called a "zero day exploit" and is rewarded with a news headline; so its not quite that.

We intermix python and scheme quite a lot; most of the chatbot is in scheme; the robot interfaces are in ROS which is python. It's hard to imagine that AnaphoraUTest manages to mix these two together even more than other parts, but ... well its a guessing game, and its not a component we actively use right now, so the incentive to debug is minor.

BTW, AnaphoraUTest passes for me, without any issues. I'm running Python 3.5.3 and guile (GNU Guile) 2.9.2
and Boehm GC with the "huge" memory model. My latest guess is that this the failure stems from not using the "huge" memory model.