pgsql/src bin/psql/command.c include/config.h. ...

Поиск
Список
Период
Сортировка
От Bruce Momjian - CVS
Тема pgsql/src bin/psql/command.c include/config.h. ...
Дата
Msg-id 200101240342.f0O3gcG04762@hub.org
обсуждение исходный текст
Список pgsql-committers
CVSROOT:    /home/projects/pgsql/cvsroot
Module name:    pgsql
Changes by:    momjian@hub.org    01/01/23 22:42:38

Modified files:
    src/bin/psql   : command.c
    src/include    : config.h.win32

Log message:
    Here is a patch to make the current snapshot compile on Win32 (native, libpq
    and psql) again. Changes are:
    1) psql requires the includes of "io.h" and "fcntl.h" in command.c in order
    to make a call to open() work (io.h for _open(), fcntl.h for the O_xxx)
    2) PG_VERSION is no longer defined in version.h[.in], but in configure.in.
    Since we don't do configure on native win32, we need to put it in
    config.h.win32 :-(
    3) Added define of SYSCONFDIR to config.h.win32 - libpq won't compile
    without it. This functionality is *NOT* tested - it's just defined as "" for
    now. May work, may not.
    4) DEF_PGPORT renamed to DEF_PGPORT_STR

    I have done the "basic tests" on it - it connects to a database, and I can
    run queries. Haven't tested any of the fancier functions (yet).

    However, I stepped on a much bigger problem when fixing psql to work. It no
    longer works when linked against the .DLL version of libpq (which the
    Makefile does for it). I have left it linked against this version anyway,
    pending the comments I get on this mail :-)
    The problem is that there are strings being allocated from libpq.dll using
    PQExpBuffers (for example, initPQExpBuffer() on line 92 of input.c). These
    are being allocated using the malloc function used by libpq.dll. This
    function *may* be different from the malloc function used by psql.exe - only
    the resulting pointer must be valid. And with the default linking methods,
    it *WILL* be different. Later, psql.exe tries to free() this string, at
    which point it crashes because the free() function can't find the allocated
    block (it's on the allocated blocks list used by the runtime lib of
    libpq.dll).

    Shouldn't the right thing to do be to have psql call termPQExpBuffer() on
    the data instead? As it is now, gets_fromFile() will just return the pointer
    received from the PQExpBuffer.data (this may well be present at several
    places - this is the one I was bitten by so far). Isn't that kind of
    "accessing the internals of the PQExpBuffer structure" wrong? Instead,
    perhaps it shuold make a copy of the string, adn then termPQExpBuffer() it?
    In that case, the string will have been allocated from within the same
    library as the free() is called.

    I can get it to work just fine by doing this - changing from (around line
    100 of input.c):
    and the same a bit further down in the same function.

    But, as I said above, this may be at more places in the code? Perhaps
    someone more familiar to it could comment on that?

    What do you think shuld be done about this? Personally, I go by the "If you
    allocate a piece of memory using an interface, use the same interface to
    free it", but the question is how to make it work :-)

    Also, AFAIK this only affects psql.exe, so the changes made to the libpq
    this patch are required no matter how the other issue is handled.

    Regards,
    Magnus


В списке pgsql-committers по дате отправления:

Предыдущее
От: Bruce Momjian - CVS
Дата:
Сообщение: pgsql/contrib/pgcrypto Makefile README.pgcrypt ...
Следующее
От: Bruce Momjian - CVS
Дата:
Сообщение: pgsql/src/backend/main main.c