| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Jeremy Evans <code(at)jeremyevans(dot)net> |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables |
| Date: | 2018-09-07 18:15:22 |
| Message-ID: | 20180907181522.GB32058@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Fri, Sep 07, 2018 at 10:55:18AM -0700, Jeremy Evans wrote:
> Here's the backtrace:
>
> #5 0x000017c20a6b8b00 in pg_fe_scram_free (opaq=0x17c223712000) at fe-auth-scram.c:127
> #6 0x000017c20a6b9d20 in pqDropConnection (conn=0x17c1dac61800, flushInput=1 '\001') at fe-connect.c:479
> #7 0x000017c20a6bf95e in closePGconn (conn=0x17c1dac61800) at fe-connect.c:3710
>
> Hopefully this helps. If you need more information, please let me know.
Thanks. This fails when freeing the password field in fe_scram_state.
I have a question: does your password use non-ASCII characters which
could make SASLprep to be run on the password string? The result string
from pg_saslprep allocates a new string for any results returned by
reading the code, I am wondering if we could be missing something..
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeremy Evans | 2018-09-07 18:50:03 | Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables |
| Previous Message | Jeremy Evans | 2018-09-07 17:55:18 | Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables |