[mercury-users] Strange segfault has moved

[Ondrej Bojar]

Hi.

I'm trying to catch a strange segfault in a quite a big Mercury+C+CPP
(using libraries and sockets to connect to a server written in Free
Pascal) project for fourteen days already.

I'd be very grateful to anybody who would wish to try to reproduce the bug
or possibly suggest any hint. I've tried to use mpatrol or efence to watch
for any heap misuse, but I was not able to link any of the libraries
together with the code from Mercury. Is anybody aware of any library
compatible with Mercury to perform such checks?

The bug is hard to locate, the program runs correctly and suddently a
malloc segfaults. Yesterday, I thought I have very bad news, because the
bug with segfaulting had vanished for a while, although I hadn't done any
important changes to the code. Fortunately, it hadn't vanished, it had
just moved :-)

Now the program (the "chatter") runs, exchanges strings from C to Mercury
and back again etc (although the implementation is still the leaky one, as
discussed earlier on this forum). It loops ad infinitum when it finishes,
i.e. the pred main is called again and again whenever it returns.

Here is the tail of the output of the chatter. The "AI" is "atomic
instruction", in every turn of the simulation, this is exchanged with the
server. The server returns some data and some flags. Some of the flags are
combined into a single DeadFlag. As long as the DeadFlag is 'alive' the
simulation is running and the chatter should proceed. Once the DeadFlag
changes to 'simulation_halted', the loop predicate of the chatter is
stopped and returns back to main. The main then prints out the message
'Chatter finishes' and succeeds. Suddenly, the main gets called again and
tries to connect to the server again.

A noteworthy thing is that the main doesn't loop, if the server is not
contacted (chatter --static=foo; see below).

----------------------------

*** Sending AI header ***
Myself: 0fff000a
Object: 00000000
Instrument: 00000000
AI code: 01120000
Data length: 01160000
Data sent:
c_receive_world_changes: received
 - heard ><
 - dead 0
 - status 1
string_to_utterances: The String:
RetVal: 0
DeadFlag: alive
Uttrs: []
Got Utterances: []
Got Last RetVal: 0
Sending: nop

*** Sending AI header ***
Myself: 0fff000a
Object: 00000000
Instrument: 00000000
AI code: 01120000
Data length: 01160000
Data sent:
c_receive_world_changes: received
 - heard ><
 - dead 0
 - status -1
string_to_utterances: The String:
RetVal: 0
DeadFlag: simulation_halted
Uttrs: []
The simulation was halted. Quitting.
Chatter finishes.
db_init: db_inicializace successfull
Connecting to server at: localhost:24444
c_connect_to_server: called
connect_to_server: socket created with result -1
c_connect_to_server: received
 - heard ><
 - arg ><
 - dead 0
 - status -1
communicator: failed to connect to the server
Failed to connect.
Chatter finishes.
db_init: db_inicializace successfull
Connecting to server at: localhost:24444
c_connect_to_server: called
connect_to_server: socket created with result -1
c_connect_to_server: received

------------------------(this loops)-------------


I'd be very interested, if anybody could reproduce the behaviour. I've
tried to reproduce it on a different computer and the former version of
the bug appeared -- the chatter has crashed at a malloc quite early after
exchanging some initial data with the server.

The project is rather big and a bit messy.

The complete tree is available at http://drson.lupa.cz/~obo/enti.tgz
A brief description in English is available in the file
doc/promo/ents_description.txt in the package and the intended chatter is
described at
http://nats-wiki.informatik.uni-hamburg.de/twiki/bin/view/Nats/EntsChatter


I'm using Mercury Compiler, version rotd-2003-03-03, configured for
i686-pc-linux-gnu. My gcc is 2.96.


To compile the package you need Qt (2.x or 3.x), SDL, Free Pascal, and
Mercury.

(For Debian Linux, Fergus Henderson sent me some extra comments
        - It took me a while to find out the Debian package name
          for Free Pascal (it is `fp-compiler').
        - I needed to install QT as well
          (Debian packages `libqt-dev' and `libqt-dev-mt').
        - On Debian Linux, QT is installed in /usr/include/qt,
          /usr/bin, and /usr/lib.  I had to create a /tmp/fjh/qt
          directory, containing symlinks:
                bin -> /usr/bin
                lib -> /usr/lib
                include -> /usr/include/qt
)

Once you've all the prerequisites, use the following commands to compile
it:

./configure
make
make install
  (this will ask you where to install and then tell you the three env.vars
  to set, both the question and the hints are in Czech, sorry; the project
  is still under the big change for international audience)


To compile the problematic chatter use then:

cd enti/src/chatter
mmake depend
mmake


(The chatter relies on a library of common routines, this library is
already compiled in the directory src/ent/lingv2 by 'mmake libcore' during
the main compilation phase.)

To run the chatter use:


## Shell nr. 1
### Set the environment variables
cd enti/src/sample_chatter_world
make myWorld.inst
entiserver start

## Then shell nr. 2
### Set the environment variables
cd enti/src/sample_chatter_world
entiprohlizec -s localhost -p 24444

## Then shell nr. 3
cd enti/src/chatter
./chatter


Now in the browser window you should be able to walk with the
blue-trousered (ag)ent. Click a tile not too far away from him. The black
guy is the chatter and is idle. (You can try to speak to the chatter, but
his linguistic module is blank so far -- it was not that blank in Czech in
the former version, but it was hard to understand for foreigners :-)

To stop the simulation, use the Disconnect command from the menu Session
of the browser. Stopping the simulation from the browser will send the
server a message to stop, and the server will spread this message to all
the participants, i.e. also to the chatter.

The chatter then loops and infinitum as described.

-----

Running the chatter in console mode only, no server needed (and no bug
experienced!):

cd enti/src/chatter
./chatter --static=foo

The dialogue is then performed on the console, no database dump file is
read in fact, this is not implemented yet -- the database is not touched
yet.

klokan:chatter$./chatter --static=foo
Loading the database dump file: foo
Starting to chat on the console, the user is the ent id XXX
Say something:
> Hi.
Received: Hi.
Got Utterances: [utterance(268369920, 0, "Hi.")]
Got Last RetVal: 0
I say: Sorry, I understand only plain numbers.
> 123
Received: 123
Got Utterances: [utterance(268369920, 0, "123")]
Got Last RetVal: 0
I say: 123 plus 1 is 124
>

Use Ctrl-D to quit the chatter. No infinite loop will happen.

I'd be very grateful for any hints what to look for in order to get rid of
the bug.

Thanks, Andrew.


--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------