Re: mysql_stmt_execute() trashing stack
Posted by: John Deal
Date: August 06, 2011 11:29AM

More work on this. After some changes, the memory corruption happens every second time a user logs into the server. I have as an automatic variable in the offending method of 2000 unsigned int as the last method variable and initials it to all 0xffffffff. This area starting at the 1984 index gets written with 0x4, 0x0, 0x4, ox0, ox4, 0x0, 0x4, 0x0 upon calling mysql_stmt_execute(). Looked at the single bind structure that is used for this call and it all looks good. All the pointers (buffer, length, etc.) point to the intended allocated method variables.

The SQL for the prepared statement is a follows:

static const char m_get_subscription_workplace_list_sql[] = "select subscriptionID, userID, workplaceID, rolesID from subscriptions where userID = ?";

Interesting is all 4 fields to be read are 32 bit (4 byte) fields. This seems to match the overridden memory with each field starting with an unsigned int length then 4 bytes to hold the data. However, continuing in the method the mysql_stmt_bind_results() statement does not affect the stack guard area. The mysql_stmt_fetch() call places the data in the appropriate variables and does not affect the stack guard area.

I am completely lost on what is happening here. mysql_stmt_execute() is writing to the stack area for some reason. Does anyone have an idea why this is taking place?

The only extremely remote possibility I can think of is a collision of the stack and heap areas. This program does not do much so I doubt this is the case but will investigate.

Thanks to all who have looked at this.

Options: ReplyQuote


Subject
Views
Written By
Posted
4743
July 26, 2011 11:42AM
1781
August 03, 2011 04:55PM
Re: mysql_stmt_execute() trashing stack
1957
August 06, 2011 11:29AM
2634
August 07, 2011 12:18PM
1657
August 07, 2011 12:26PM
2439
August 11, 2011 04:11PM
2194
August 13, 2011 01:25PM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.