#136 _mysql_exceptions.OperationalError: (2020, "Got packet bigge

MySQLdb-1.2
closed
Andy Dustman
MySQLdb (285)
5
2012-09-19
2005-05-11
Martin Mokrejs
No

Hi,
it seems to me that either _mysql or mysqldb somehow
uses small max_allowed_packet variable. At least this
is where the error message points to. my.cnf files on
both, server and client set the variable to 1GB. They
are properly honored by mysql and mysqld. I point
mysqldb to read the .my.cnf file and in principle have
no reason to think it ignores it.

However, I perform very small select statement and it
dies with the above message. It works for other rows
and the difference is that this row contains over 8k
characters in BLOB. That's not much at all and even
with often default max_allowed_packet=1M this should
still work fine.

I suspect it's a bug in the wrappers. I have tested
mysql-4.0.24, 4.1.11, all on 2 machines running linux.
No luck.

$ cat >> bug.py
from MySQLdb import connect, DatabaseError, cursors
_c = connect(read_default_file =
"/home/mmokrejs/.my.cnf", read_default_group = 'test')
_c.query("show variables")
s = _c.store_result()
print s.num_rows()
_count = s.num_rows()
_index = 0
while _count != _index:
print s.row_tell()
print s.fetch_row()
_index += 1

The output is:

184
0
(('back_log', '100'),)
4
(('basedir',
'/usr/local/mysql-standard-4.1.11-pc-linux-gnu-i686/'),)
-1431655754
(('binlog_cache_size', '32768'),)
16
(('bulk_insert_buffer_size', '8388608'),)
-1431655744
(('character_set_client', 'latin1'),)
26
(('character_set_connection', 'latin1'),)
-1431655734
(('character_set_database', 'latin1'),)
1431655802
(('character_set_results', 'latin1'),)
42
(('character_set_server', 'latin1'),)
1431655812
(('character_set_system', 'utf8'),)
-1431655714

Maybe this would point to the problem with my select
statement and explain why it looks like the
max_allowed_packet problem?

Discussion

1 2 > >> (Page 1 of 2)
  • Andy Dustman
    Andy Dustman
    2005-05-11

    Logged In: YES
    user_id=71372

    The wrappers do absolutely nothing with respect to the
    maximum packet size. Your exception is truncated so
    something important could be missing there.

    However, you are using MySQLdb in a really screwed-up way.
    query() is a low-level API function. Your code should look
    like this:

    from MySQLdb import connect
    db = connect(read_default_file =
    "/home/mmokrejs/.my.cnf", read_default_group = 'test')
    c = db.cursor()
    c.execute("show variables")
    for row in c: # or c.fetchall()
    print row

    Read PEP-249; a copy is included in the source distribution.

     
  • Martin Mokrejs
    Martin Mokrejs
    2005-05-11

    Logged In: YES
    user_id=696559

    I have improved the testcase I wanted to submit, so here it is:

    reading row 480 with sequence_string long 8169 chars.
    reading row 481 with sequence_string long 8170 chars.
    reading row 482 with sequence_string long 8171 chars.
    reading row 483 with sequence_string long 8172 chars.
    reading row 484 with sequence_string long 8173 chars.
    reading row 485 with sequence_string long 8174 chars.
    reading row 486 with sequence_string long 8175 chars.
    reading row 487 with sequence_string long 8176 chars.
    reading row 488 with sequence_string long 8177 chars.
    reading row 489 with sequence_string long 8178 chars.
    reading row 490 with sequence_string long 8179 chars.
    reading row 491 with sequence_string long 8180 chars.
    reading row 492 with sequence_string long 8181 chars.
    reading row 493 with sequence_string long 8182 chars.
    Traceback (most recent call last):
    File "bug.py", line 21, in ?
    s = _c.use_result().fetch_row()
    _mysql_exceptions.OperationalError: (2020, "Got packet
    bigger than 'max_allowed_packet' bytes")
    $

     
  • Martin Mokrejs
    Martin Mokrejs
    2005-05-11

    Logged In: YES
    user_id=696559

    Yes, I use cursors in my programs, mostly DictCursor, but
    for the testace have tried to connection itself ... as you
    say cursors are emulated.

     
  • Martin Mokrejs
    Martin Mokrejs
    2005-05-11

    test table definition

     
    Attachments
  • Martin Mokrejs
    Martin Mokrejs
    2005-05-11

    same testcase with cursors, if you wish

     
    Attachments
  • Andy Dustman
    Andy Dustman
    2005-05-11

    Logged In: YES
    user_id=71372

    I see. I think it would make sense for you to make a
    subclass of SSDictCursor, which uses use_result()
    internally, and put your debugging code in there.

    Still, your original test case never does print
    max_allowed_packet. You should be able to do this query:

    select @@max_allowed_packet

    to get this value directly.

    Have you tried an intermediate value in your configuration,
    such as 512M? I wonder if there is some boundary condition
    problem. Anyway, all of the packet size stuff is handled in
    the C API, and MySQLdb/_mysql does not mess with it in any
    way, so it's very unlikely to be a MySQLdb bug, but perhaps
    a libmysqlclient bug.

     
  • Martin Mokrejs
    Martin Mokrejs
    2005-05-11

    Logged In: YES
    user_id=696559

    Did you reproduce it? If breaks for me even with cursors.

     
  • Martin Mokrejs
    Martin Mokrejs
    2005-05-11

    Logged In: YES
    user_id=696559

    Well, I think the error message is simply wrong. I used to
    get "connection lost" but after I turned off the compression
    (which is not very usefull as it the client/server protocol
    according to Michael Widenius cannot send a response back
    when compression is enabled).

    How about the row numbers being negative, huge positive etc?

    I don't undertand your note about SSDictCursor, what should
    I get? Example? ;) Many thanks for quick response.

     
  • Andy Dustman
    Andy Dustman
    2005-05-11

    Logged In: YES
    user_id=71372

    .row_tell() simply does not work with .use_result(); this is
    documented:

    http://dev.mysql.com/doc/mysql/en/mysql-row-tell.html

    In my ~/.my.cnf, I added this to the [client] section:

    max_allowed_packet = 512M

    import MySQLdb

    db=MySQLdb.connect(host="mysql",read_default_file="~/.my.cnf")
    c=db.cursor()
    c.execute('select @@max_allowed_packet')
    1L
    c.fetchone()
    (1047552L,)

    Bug? Perhaps, but not in MySQLdb:

    $ mysql -h mysql
    Welcome to the MySQL monitor. Commands end with ; or \g.
    Your MySQL connection id is 1986 to server version: 4.0.24

    Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

    mysql> select @@max_allowed_packet;
    +----------------------+
    | @@max_allowed_packet |
    +----------------------+
    | 1047552 |
    +----------------------+
    1 row in set (0.00 sec)

    In fact, even if I use the --max_allowed_packet= option to
    the mysql CLI, this does not affect the results. I am using
    MySQL-4.0 for these tests because that's what's available at
    the moment.

    My point with SSDictCursor was that you could subclass it
    and override _do_query() and insert your debugging code
    there, rather than trying to write it explicitly in your
    test case.

     
  • Martin Mokrejs
    Martin Mokrejs
    2005-05-11

    Logged In: YES
    user_id=696559

    per not about row_tell(), would mysqldb return None or some

    exception when not used after mysql_store_result()? ;)

    Regarding the max_allowed_packet = 512M not being honored,
    you have to put it into /etc/my.cnf into [mysqld] section
    and restart!

    The max_allowed_packet I had even just 1M or 15M or 16M.
    Doesn't help.
    I known these trick from older 4.0. <.10 days, when values
    above 16M did not work. I just want to emphasize, I don't
    believe it's related to max_alowed_packet at all and the
    errmsg is wrong.

    Did you run the testcases? Do you get the crash with 8182
    chars when SELECTed? -- Note, if it would be
    max_allowed_problem, I couldn't even insert the row. If I'd
    update by merging to rows, I might be affected by
    net_buffer_length too. Anyway, with 8182 characters?

    Unfortunately I'm not skilled in C, how can I proof it's
    libmysqlclient bug?

     
  • Andy Dustman
    Andy Dustman
    2005-05-11

    Logged In: YES
    user_id=71372

    I can't try your test case right away.

    It would be possible to return an exception or None from
    .row_tell(), but since it's not something you should be
    using, it's not a high priority. In a portable DB API
    program, you should use cursor.rownumber to find out where
    you are. This works with both the standard cursor and
    SSCursor variants. However, it may be a fairly simple test
    in _mysql.c, so I might still implement it.

     
  • Martin Mokrejs
    Martin Mokrejs
    2005-05-11

    Logged In: YES
    user_id=696559

    bug.py works with:

    [cut]
    building '_mysql' extension
    i686-pc-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG
    -fPIC -I/usr/local/mysql-max-4.0.15-pc-linux-i686/include
    -I/usr/include/python2.3 -c _mysql.c -o
    build/temp.linux-i686-2.3/_mysql.o
    _mysql.c: In function _mysql_ConnectionObject_info': _mysql.c:1150: warning: assignment discards qualifiers from pointer target type _mysql.c: In function_mysql_ConnectionObject_stat':
    _mysql.c:1379: warning: assignment discards qualifiers from
    pointer target type
    _mysql.c: At top level:
    _mysql.c:2007: warning: initialization from incompatible
    pointer type
    _mysql.c:2096: warning: initialization from incompatible
    pointer type
    i686-pc-linux-gnu-gcc -pthread -shared
    build/temp.linux-i686-2.3/_mysql.o
    -L/usr/local/mysql-max-4.0.15-pc-linux-i686/lib
    -lmysqlclient_r -lz -o build/lib.linux-i686-2.3/_mysql.so
    /home/mmokrejs/tmp/MySQL-python-0.9.2 # ldd
    build/lib.linux-i686-2.3/_mysql.so
    linux-gate.so.1 => (0xffffe000)
    libz.so.1 => /lib/libz.so.1 (0xb7f93000)
    libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7f80000)
    libc.so.6 => /lib/tls/libc.so.6 (0xb7e4f000)
    /lib/ld-linux.so.2 (0x80000000)
    /home/mmokrejs/tmp/MySQL-python-0.9.2 #

     
  • Martin Mokrejs
    Martin Mokrejs
    2005-05-11

    Logged In: YES
    user_id=696559

    It does NOT work with:

    building '_mysql' extension
    creating build/temp.linux-i686-2.3
    i686-pc-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG
    -fPIC -I/usr/local/mysql-max-4.0.18-pc-linux-i686/include
    -I/usr/include/python2.3 -c _mysql.c -o
    build/temp.linux-i686-2.3/_mysql.o
    i686-pc-linux-gnu-gcc -pthread -shared
    build/temp.linux-i686-2.3/_mysql.o
    -L/usr/local/mysql-max-4.0.18-pc-linux-i686/lib
    -lmysqlclient -lz -o build/lib.linux-i686-2.3/_mysql.so
    /home/mmokrejs/tmp/MySQL-python-1.0.0 #

     
  • Andy Dustman
    Andy Dustman
    2005-05-11

    Logged In: YES
    user_id=71372

    There are too many things changing here. Your tests (so far)
    are:

    MySQLdb with MySQL result
    0.9.2 4.0.15 pass
    1.0.0 4.0.18 fail
    1.2.0 4.1.11 fail

    From this, it's not possible to conclude that MySQLdb is the
    problem; it could as well be some change from MySQL-4.0.15
    to .18. I assume you are running the same client and server
    versions, but I probably shouldn't assume this.

     
  • Martin Mokrejs
    Martin Mokrejs
    2005-05-11

    Logged In: YES
    user_id=696559

    To summarize, I have tested in the below cases against
    single server, being 4.1.11. I have a different config file,
    so I think that explains the change from the
    max_allowed_packet message back to the 'MySQL server has
    gone away'. I didn't investigate but I think it's because of
    the compression turned on. It sucks, but as Michael Widenius
    explained me once in some bugreport
    on bugs.mysql.com, the server has no way to tell the client.
    Still, there are
    cases when client kills the connection first and in theory
    could spit improved
    message. The bug is still open as it requires major rework
    of the protocol.

    So, to be clear, here is what I get once again:

    [cut]
    reading row 3027 with sequence_string long 8181 chars.
    Traceback (most recent call last):
    File "bug.py", line 13, in ?
    _cursor.execute("INSERT into sequence (sequence_string)
    values ('" + _str + "')")
    File
    "/usr/lib/python2.3/site-packages/MySQLdb/cursors.py", line
    137, in execute
    self.errorhandler(self, exc, value)
    File
    "/usr/lib/python2.3/site-packages/MySQLdb/connections.py",
    line 33, in defaulterrorhandler
    raise errorclass, errorvalue
    _mysql_exceptions.OperationalError: (2006, 'MySQL server has
    gone away')

    mysql-python-1.2.0 breaks when built with mysql-4.0.24
    (2006, 'MySQL server has gone away')

    mysql-python-1.2.0 breaks when built with mysql-4.0.21
    (2006, 'MySQL server has gone away')

    mysql-python-1.2.0 breaks when built with mysql-4.0.18
    (2006, 'MySQL server has gone away')

    mysql-python-1.2.0 doesn't build with mysql-4.0.15

    mysql-python-1.0.0 breaks when built with mysql-4.0.18
    (2006, 'MySQL server has gone away')

    mysql-python-1.0.0 works when built with mysql-4.0.15

    mysql-python-0.9.2 works when built with mysql-4.0.15

     
  • Martin Mokrejs
    Martin Mokrejs
    2005-05-11

    Logged In: YES
    user_id=696559

    Updated overview (in the previous post I had some
    non-reproducible false error. Probably I've failed to
    uninstall mysql-python. Now everything carefully re-tested
    and improved.

    mysql-python-1.2.0 breaks when built with mysql-4.0.24
    (2006, 'MySQL server has gone away')

    mysql-python-1.2.0 breaks when built with mysql-4.0.22
    (2006, 'MySQL server has gone away')

    mysql-python-1.2.0 breaks when built with mysql-4.0.21
    (2006, 'MySQL server has gone away')

    mysql-python-1.2.0 breaks when built with mysql-4.0.18
    (2006, 'MySQL server has gone away')

    mysql-python-1.2.0 breaks when built with mysql-4.0.16
    (2006, 'MySQL server has gone away')

    mysql-python-1.2.0 doesn't build with mysql-4.0.15

    mysql-python-1.0.1 doesn't build with mysql-4.1.6

    mysql-python-1.0.1 doesn't build with mysql-4.0.24

    mysql-python-1.0.1 works when built with mysql-4.0.22

    mysql-python-1.0.0 doesn't build with mysql-4.1.7

    mysql-python-1.0.0 doesn't build with mysql-4.1.6

    mysql-python-1.0.0 doesn't build with mysql-4.0.24

    mysql-python-1.0.0 works when built with mysql-4.0.22

    mysql-python-1.0.0 works when built with mysql-4.0.21

    mysql-python-1.0.0 works when built with mysql-4.0.18

    mysql-python-1.0.0 works when built with mysql-4.0.17

    mysql-python-1.0.0 works when built with mysql-4.0.16

    mysql-python-1.0.0 works when built with mysql-4.0.15

    mysql-python-0.9.2 works when built with mysql-4.0.15

     
  • Andy Dustman
    Andy Dustman
    2005-05-11

    Logged In: YES
    user_id=71372

    If MySQLdb-1.2.0 doesn't build with 4.0.16, put in a
    separate bug. but make sure it's not a duplicate of this bug
    first:

    https://sourceforge.net/tracker/index.php?func=detail&aid=1146226&group_id=22307&atid=374932

    If it is due to some behavior in mysql_config, use the
    existing bug.

    As previously noted, MySQLdb-1.0 does not support MySQL-4.1.
    It's possible to make it compile with a very simple patch,
    but I want to discourage people from using 1.0 as much as
    possible (you should only use it if you have Python older
    than 2.2).

    Are you still doing these tests with compression turned on?
    Also, see if anything interesting shows up in the mysqld.err
    log on the server.

     
  • Martin Mokrejs
    Martin Mokrejs
    2005-05-11

    Logged In: YES
    user_id=696559

    MySQLdb-1.2.0 DOES build with 4.0.16, but the test breaks.
    In every case I have visually verified the compile and link
    command lines in output. I use full path to
    /usr/local/mysql-(standard|max)-$version and no symlink
    /usr/local/mysql exists at the moment. Also, no /usr/
    installed mysql exists.
    I really compiled and linked against what I said. ;) In the
    output below (which should convince it's not a duplicate of
    that bug) you will see printed the list cause by this change
    to setup.py:

     extra_compile_args = config("cflags")
    
    • extra_compile_args.append('-O0')
    • extra_compile_args.append('-g3')
    • print str(extra_compile_args)

    /home/mmokrejs/tmp/MySQL-python-1.0.1 # cd ../MySQL-python-1.2.0
    root@aquarius /home/mmokrejs/tmp/MySQL-python-1.2.0 # rm -rf
    build/lib.linux-i686-2.3/
    root@aquarius /home/mmokrejs/tmp/MySQL-python-1.2.0 # export
    PATH=/usr/local/mysql-max-4.0.16-pc-linux-i686/bin:$PATH
    /home/mmokrejs/tmp/MySQL-python-1.2.0 # python setup.py build
    ['-I/usr/local/mysql-max-4.0.16-pc-linux-i686/include',
    '-mpentiumpro', '-DBIG_TABLES', '-O0', '-g3']

    running build
    running build_py
    creating build/lib.linux-i686-2.3
    copying _mysql_exceptions.py -> build/lib.linux-i686-2.3
    creating build/lib.linux-i686-2.3/MySQLdb
    copying MySQLdb/init.py -> build/lib.linux-i686-2.3/MySQLdb
    copying MySQLdb/converters.py ->
    build/lib.linux-i686-2.3/MySQLdb
    copying MySQLdb/connections.py ->
    build/lib.linux-i686-2.3/MySQLdb
    copying MySQLdb/cursors.py -> build/lib.linux-i686-2.3/MySQLdb
    copying MySQLdb/sets.py -> build/lib.linux-i686-2.3/MySQLdb
    copying MySQLdb/times.py -> build/lib.linux-i686-2.3/MySQLdb
    copying MySQLdb/stringtimes.py ->
    build/lib.linux-i686-2.3/MySQLdb
    copying MySQLdb/mxdatetimes.py ->
    build/lib.linux-i686-2.3/MySQLdb
    copying MySQLdb/pytimes.py -> build/lib.linux-i686-2.3/MySQLdb
    creating build/lib.linux-i686-2.3/MySQLdb/constants
    copying MySQLdb/constants/init.py ->
    build/lib.linux-i686-2.3/MySQLdb/constants
    copying MySQLdb/constants/CR.py ->
    build/lib.linux-i686-2.3/MySQLdb/constants
    copying MySQLdb/constants/FIELD_TYPE.py ->
    build/lib.linux-i686-2.3/MySQLdb/constants
    copying MySQLdb/constants/ER.py ->
    build/lib.linux-i686-2.3/MySQLdb/constants
    copying MySQLdb/constants/FLAG.py ->
    build/lib.linux-i686-2.3/MySQLdb/constants
    copying MySQLdb/constants/REFRESH.py ->
    build/lib.linux-i686-2.3/MySQLdb/constants
    copying MySQLdb/constants/CLIENT.py ->
    build/lib.linux-i686-2.3/MySQLdb/constants
    running build_ext
    building '_mysql' extension
    i686-pc-linux-gnu-gcc -pthread -shared
    build/temp.linux-i686-2.3/_mysql.o
    -L/usr/local/mysql-max-4.0.16-pc-linux-i686/lib
    -lmysqlclient_r -lpthread -lz -lcrypt -lnsl -lm -lpthread
    -lc -lnss_files -lnss_dns -lresolv -lc -lnss_files -lnss_dns
    -lresolv -lmysqlclient_r -o build/lib.linux-i686-2.3/_mysql.so
    /home/mmokrejs/tmp/MySQL-python-1.2.0 # python setup.py install
    ['-I/usr/local/mysql-max-4.0.16-pc-linux-i686/include',
    '-mpentiumpro', '-DBIG_TABLES', '-O0', '-g3']

    Regarding logs, nothing interresting in there. Regarding the
    compression or why this error message, I haven't inspected
    yet. Make me happy and give me a patch to compile 1.0.1
    against 4.0.24. Let's see what happens then! ;)

     
  • Andy Dustman
    Andy Dustman
    2005-05-11

    Logged In: YES
    user_id=71372

    Sorry, I guess you said that it wouldn't build against
    4.0.15, not .16; probably a typo on my part.

     
  • Martin Mokrejs
    Martin Mokrejs
    2005-05-11

    Logged In: YES
    user_id=696559

    Some news. The (2006, 'MySQL server has gone away') is
    generated when I have "max_allowed_packet=$anything" in
    either the default group I specifically ask to be used on
    the connect line or in [mysql] section of the same config file.
    I really mean when I comment both such occurencies in that
    .my.cnf file, the connection doesn't break after processing
    those many (8180) records and doing commit after each but
    happily continues utill the InnoDB table is full. This
    happened to me using 1.2.0 compiled against 4.0.16.

    The values tested were 1M, 16M, 1GB and empty
    (^max_allowed_packet=$) . I still can't comment where is the
    bug.

    Yes, 1.2.0 also in my case can't be built against 4.0.15
    because of the bug in mysql_config, returning:

    /home/mmokrejs/tmp/MySQL-python-1.2.0 #
    /usr/local/mysql-max-4.0.15-pc-linux-i686/bin/mysql_config
    Usage:
    /usr/local/mysql-max-4.0.15-pc-linux-i686/bin/mysql_config
    [OPTIONS]
    Options:
    --cflags
    [-I'/usr/local/mysql-max-4.0.15-pc-linux-i686/include']
    --libs
    [-L'/usr/local/mysql-max-4.0.15-pc-linux-i686/lib'
    -lmysqlclient -lz -lcrypt -lnsl -lm -lc -lnss_files
    -lnss_dns -lresolv -lc -lnss_files -lnss_dns -lresolv]

    --socket [/tmp/mysql.sock]
    --port [3306]
    --version [4.0.15]
    --libmysqld-libs
    -L'/usr/local/mysql-max-4.0.15-pc-linux-i686/lib' -lmysqld
    -lpthread -lz -lcrypt -lnsl -lm -lpthread -lc -lnss_files
    -lnss_dns -lresolv -lc -lnss_files -lnss_dns -lresolv -lrt

    /home/mmokrejs/tmp/MySQL-python-1.2.0 #

     
  • Andy Dustman
    Andy Dustman
    2005-05-12

    Logged In: YES
    user_id=71372

    See if 1.2.1c3 fixes your build problems. row_tell() and
    row_seek() raise ProgrammingError if you used conn.use_result().

     
  • Logged In: NO

    With 1.2.1c3 I do not get ProgrammingError, but the code

    from MySQLdb import connect, DatabaseError, cursors
    _c = connect(read_default_file = "/home/mmokrejs/.my.cnf")
    _c.query("show variables")
    s = _c.use_result()
    print s.num_rows()

    $ python bug2.py && echo passed
    0
    passed
    $

     
  • Logged In: NO

    Sorry for the previous post, it did not contain row_tell()
    anymore. Here it is again for 1.2.1c3.

      1 from MySQLdb import connect, DatabaseError, cursors
      2 _c = connect(read_default_file =
    

    "/home/mmokrejs/.my.cnf")
    3 _c.query("show variables")
    4 s = _c.use_result()
    5 print s.num_rows()
    6 _count = s.num_rows()
    7 _index = 0
    8 while _count != _index:
    9 print s.row_tell()
    10 print s.fetch_row()
    11 _index += 1

    $ python bug2.py && echo passed
    0
    passed
    $

     
  • Logged In: NO

    I still can't build 1.2.1c3 using brokem mysql_config:

    running build_ext
    building '_mysql' extension
    creating build/temp.linux-i686-2.3
    i686-pc-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG
    -fPIC -I/usr/include/python2.3 -c _mysql.c -o
    build/temp.linux-i686-2.3/_mysql.o
    -I'/usr/local/mysql-max-4.0.15-pc-linux-i686/include'
    _mysql.c:41:19: mysql.h: No such file or directory
    _mysql.c:42:26: mysqld_error.h: No such file or directory
    _mysql.c:43:20: errmsg.h: No such file or directory

     
  • Andy Dustman
    Andy Dustman
    2005-05-12

    Logged In: YES
    user_id=71372

    It is never reaching s.row_tell() in your latest example. I
    suppose I should make .num_rows() raise ProgrammingError as
    well for the .use_result() case.

    Take a look at setup.py and see if you see something I
    don't. It ought to be removing those quotes, unless maybe
    they aren't normal quotes. They look normal. I do not have a
    system I am able to replicate this on.

     
1 2 > >> (Page 1 of 2)