[Vortex] Vortex on Mac OS X

[Francis Brosnan Blazquez]

Hi Adam,

> In each of the Makefiles I made these changes:
> 
> PTHREAD_CFLAGS = none
> PTHREAD_LIBS = -lpthread
> 
> to
> 
> PTHREAD_CFLAGS = -pthread
> PTHREAD_LIBS = -lpthread
> 
> Apparently this was the last option I tried. I did also try:
> 
> PTHREAD_CFLAGS = 
> PTHREAD_LIBS = -lpthread

This is interesting. Those flags are the ones that should be selected on
gnu+unix platforms...:-?

Could you post your config.log file? It should show why your compiler is
not detecting proper threading flag. Maybe you should prefix CC=gcc your
make command?

BTW, which gcc version you use?

In the same direction, if you come with a fix, keep in mind it should be
done inside configure.ac file (located at svn [1]), rather modificating
Makefiles directly which is problematic.

> and some other combinations which I neglected to write down. They all
> compiled and gave the same results in gdb.
> 
> I also changed:
> 
> PYTHON_CFLAGS =
> -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -arch i386 -arch x86_64 -arch ppc
> 
> to 
> 
> PYTHON_CFLAGS =
> -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -arch i386

I believe this is a problem that has to do with your python
installation. Those PYTHON_CFLAGS are retrieved by vortex configure.ac
by using python-config command. What is the output if you execute?:

>> python-config --cflags

> >>        In the source files I corrected a number of warnings, mostly
> >>        printf statements without formatting strings. I also
> corrected
> >>        formatting strings where the arguments were of a different
> >>        type due to platform differences (e.g. off_t is 64 bit on OS
> >>        X).
> > 
> > I think this issues are already fixed on svn. Maybe you can also
> post
> > this changes to check if they can be integrated into SVN.
> 
> Sure, here is the output of a diff between my modified version and a
> clean copy from the tarball (with the build files removed from the
> listing):

The following set of issues around %s and printf were already fixed in
svn [2]. Could you check them?

The rest of cases follows:

Technically, long int is an alias to long which is the type of .tv_usec
structure. Which error reports your compiler here? 

> 196c196
> <               count, stop.tv_sec, (long int)stop.tv_usec);
> ---
> >               count, stop.tv_sec, stop.tv_usec);

There is no easy way to fix the following issue since placing your
change will break other platforms. Because its a regression test and no
one cares about this message, I've opted to update error message to
avoid referencing to status.st_size.

> diff -r svn-vortex/test/vortex-regression-client.c
> vortex-1.1.3.b4295.g4297/test/vortex-regression-client.c
> 2850,2851c2850,2851
> <               fprintf (stdout, "Unable to properly read the file,
> size expected to read %lld, wasn't fulfilled",
> <                        (long long)status.st_size);
> ---
> >               fprintf (stdout, "Unable to properly read the file,
> size expected to read %ld, wasn't fulfilled",
> >                        status.st_size);

The rest of exarg.c errors were also fixed at svn. Check them.

> (gdb) b __vortex_io_waiting_poll_clear
> Breakpoint 1 at 0xa29bd9: file vortex_io.c, line 311.
> (gdb) run
> Starting
> program: /Users/adamcox/Development/Vortex/svn/svn-vortex/test/.libs/vortex-regression-listener 
> Reading symbols for shared libraries .+++++++++++++++.......... done
> ready and waiting..
> [Switching to process 75802]
> 
> Breakpoint 1, __vortex_io_waiting_poll_clear (__fd_group=0x409160) at
> vortex_io.c:311
> 311             poll->length = 0;
> (gdb) display poll
> Unable to access variable "poll"
> 1: poll = <variable optimized away by compiler>
> (gdb) display (VortexPoll *)__fd_group
> 2: (VortexPoll *) __fd_group = (VortexPoll *) 0x409160
> (gdb) display ((VortexPoll *)__fd_group)->length
> 3: ((VortexPoll *) __fd_group)->length = 0
> (gdb) display ((VortexPoll *)__fd_group)->set
> 4: ((VortexPoll *) __fd_group)->set = (struct pollfd *) 0x0
> (gdb) display ((VortexPoll *)__fd_group)->max
> 5: ((VortexPoll *) __fd_group)->max = -1
> (gdb) display sizeof(struct pollfd)
> 6: 8 = 8
> (gdb) bt
> #0  __vortex_io_waiting_poll_clear (__fd_group=0x409160) at
> vortex_io.c:311
> #1  0x0002f6b4 in __vortex_reader_run (ctx=0x804e00) at
> vortex_reader.c:1300
> #2  0x987d7a19 in _pthread_start ()
> #3  0x987d789e in thread_start ()
> 
> looks to me like memset (poll->set, 0, sizeof (struct pollfd) *
> poll->max); is going to try to write -8 bytes to memory address 0…
> that can't be good. I wouldn't know where to start to work out why
> though.

Interesting. For some reason your system is returning -1 when called to
getrlimit with RLIMIT_NOFILE..which causes the rest of the problems.
I've updated vortex io module to check value returned (max) from
vortex_get_conf, to update the value to 4096 in such cases. 

Could you check the fix introduced in the SVN to see if breaks on bzero?

Cheers!
[1] https://dolphin.aspl.es/svn/publico/af-arch/trunk/libvortex-1.1/configure.ac
[2] https://dolphin.aspl.es/svn/publico/af-arch/trunk/
-- 
Francis Brosnan Blazquez <francis at aspl.es>
ASPL