View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000443 | Pgpool-II | Bug | public | 2018-11-05 17:29 | 2018-11-19 14:04 |
| Reporter | nagata | Assigned To | nagata | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Summary | 0000443: Segmentation fault occurs when a certain Bind message is sent in native replication mode. | ||||
| Description | One of our clients reported that segmentation fault occurs with a specific query including CURRENT_DATE in native replication mode. Through my analysis of core file, I found that this occurs in bind_rewrite_timestamp(). #0 0x0000003ab50899d4 in memcpy () at ../sysdeps/x86_64/memcpy.S:444 0000001 0x000000000044588a in bind_rewrite_timestamp (backend=<value optimized out>, message=0xaa0398, orig_msg=<v alue optimized out>, len=<value optimized out>) at /usr/include/bits/string3.h:52 0000002 0x00000000004364f9 in Bind (frontend=0xa9a258, backend=0xa7f350, len=70, contents=0xaa0688 "") at protocol /pool_proto_modules.c:1343 0000003 0x0000000000436ce7 in ProcessFrontendResponse (frontend=0xa9a258, backend=0xa7f350) at protocol/pool_proto _modules.c:2396 ... We can reproduce this by a query and pgproto: 'P' "P1" "DELETE FROM test2 WHERE d = CURRENT_DATE" 0 'D' 'S' "P1" 'B' "" "P1" 1 1 0 0 'E' "" 0 'C' 'S' "" 'S' 'Y' 'X' The problem is the Bind ('B') message. The number of parameter format codes is specified to one. This means that the specified format code (this is also one (=binary) in this example) is applied to all parameters. Although the number of the original query's parameter is zero, this message is allowed in the protocol. However, this causes bind_rewrite_timestamp() to call memcpy with a negative value for size_t, because this doesn't suppose the number of parameter format codes is larger than the actual number of the parameter in the original query. I attached a patch to handle this case properly. Also, some comments and debug codes are added. | ||||
| Steps To Reproduce | Table schema: CREATE TABLE test2 (d date); pgproto: 'P' "P1" "DELETE FROM test2 WHERE d = CURRENT_DATE" 0 'D' 'S' "P1" 'B' "" "P1" 1 1 0 0 'E' "" 0 'C' 'S' "" 'S' 'Y' 'X' | ||||
| Tags | No tags attached. | ||||
|
|
|
|
|
Thank you. I will test your patch. |
|
|
I confirmed that my patch was committed. https://git.postgresql.org/gitweb/?p=pgpool2.git;a=commitdiff;h=1d8d03237a2ad507f8f1fb8fb0c84b3084f57cdc Does this means the patch was totally accepted and that this issue was resolved? If so, I would appreciate it if you could tell me when the fixed version will be released, because our client is suffering from this problem? Even if the minor version up is not planned soon, the new release of RPM, fro example, pgpool-II-pg96-3.6.13-2pgdg.rhel6.x86_64.rpm, would be appreciated. Thanks, |
|
|
Yes, we testet your patch for each branch. With your patch the issue is resovled. Thank you. But so far the next minor release or rpm update schedule is not yet decided. I will let you know as soon as it is decided. |
|
|
We decided to do minor release on November 22, 2018. |
|
|
Thank you for informing me this. I'll announce this to our client. Thanks! |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2018-11-05 17:29 | nagata | New Issue | |
| 2018-11-05 17:29 | nagata | File Added: fix_bind_rewrite_timestamp.patch | |
| 2018-11-05 17:31 | nagata | Description Updated | |
| 2018-11-06 16:53 | pengbo | Note Added: 0002239 | |
| 2018-11-14 11:36 | nagata | Note Added: 0002245 | |
| 2018-11-14 11:43 | pengbo | Note Added: 0002246 | |
| 2018-11-19 12:14 | pengbo | Note Added: 0002270 | |
| 2018-11-19 14:04 | nagata | Note Added: 0002272 | |
| 2018-11-19 14:04 | nagata | Assigned To | => nagata |
| 2018-11-19 14:04 | nagata | Status | new => resolved |
| 2018-11-19 14:04 | nagata | Resolution | open => fixed |
