On 06-04-2012 01:12, Jeffrey Walton wrote:
On Thu, Apr 5, 2012 at 6:58 PM, Jeffrey Walton wrote:
On Thu, Apr 5, 2012 at 6:06 PM, Jakob Bohm wrote:
On 4/5/2012 9:01 PM, Jeffrey Walton wrote:
[SNIP]
The following list of permission bits are most (not all) of those that
may appear in the DACL
On Thu, Apr 5, 2012 at 6:58 PM, Jeffrey Walton wrote:
> On Thu, Apr 5, 2012 at 6:06 PM, Jakob Bohm wrote:
>> On 4/5/2012 9:01 PM, Jeffrey Walton wrote:
>>>
>>> [SNIP]
>>
>> The following list of permission bits are most (not all) of those that
>> may appear in the DACL of a process on any NT deri
On Thu, Apr 5, 2012 at 6:06 PM, Jakob Bohm wrote:
> On 4/5/2012 9:01 PM, Jeffrey Walton wrote:
>>
>> On Thu, Apr 5, 2012 at 12:18 PM, sandeep kiran p
>> wrote:
>>>
>>> Jakob,
>>>
>>> The last time we had this discussions, I mentioned when 0 is passed as
>>> the
>>> second argument to CreateToolh
On 4/5/2012 6:18 PM, sandeep kiran p wrote:
Jakob,
The last time we had this discussions, I mentioned when 0 is passed as
the second argument to CreateToolhelp32Snapshot, it takes a snapshot
of all the heaps for all the processes in the system. I was wrong.
This routine only takes the snapsho
On 4/5/2012 9:01 PM, Jeffrey Walton wrote:
On Thu, Apr 5, 2012 at 12:18 PM, sandeep kiran p
wrote:
Jakob,
The last time we had this discussions, I mentioned when 0 is passed as the
second argument to CreateToolhelp32Snapshot, it takes a snapshot of all the
heaps for all the processes in the s
On Thu, Apr 5, 2012 at 12:18 PM, sandeep kiran p
wrote:
> Jakob,
>
> The last time we had this discussions, I mentioned when 0 is passed as the
> second argument to CreateToolhelp32Snapshot, it takes a snapshot of all the
> heaps for all the processes in the system. I was wrong. This routine only
Jakob,
The last time we had this discussions, I mentioned when 0 is passed as the
second argument to CreateToolhelp32Snapshot, it takes a snapshot of all the
heaps for all the processes in the system. I was wrong. This routine only
takes the snapshot of all heaps of a single process whose process
On 4/5/2012 2:22 PM, sandeep kiran p wrote:
Hi,
I had described about the deadlock we are seeing in Heap32First and
Heap32Next APIs in my previous post. Here is where you can see the post.
http://groups.google.com/group/mailing.openssl.users/browse_thread/thread/3223701a7f64a957/56d67d77c9960
Hi,
I had described about the deadlock we are seeing in Heap32First and
Heap32Next APIs in my previous post. Here is where you can see the post.
http://groups.google.com/group/mailing.openssl.users/browse_thread/thread/3223701a7f64a957/56d67d77c9960429?q=Deadlock+in+RAND_poll%27s+Heap32First+call
On 2/25/2012 3:30 PM, sandeep kiran p wrote:
MSDN says
" To enumerate the heap or module states for all processes, specify
TH32CS_SNAPALL and set /th32ProcessID/ to zero. "
So it presumably does the heap and module walk for all processes and
not only for the current process.
Aha! Missed
MSDN says
" To enumerate the heap or module states for all processes, specify
TH32CS_SNAPALL and set *th32ProcessID* to zero. "
So it presumably does the heap and module walk for all processes and not
only for the current process.
Do you think *CreateToolhelp32Snapshot's* lock on the read-only
On Fri, Feb 24, 2012 at 4:08 PM, Jakob Bohm wrote:
> On 2/24/2012 2:14 PM, sandeep kiran p wrote:
>>
>> You mentioned that OpenSSL is holding a "snapshot" lock in rand_win.c. I
>> couldn't find anything like that in that file. Can you specifically point me
>> to the code that you are referring to?
On 2/24/2012 2:14 PM, sandeep kiran p wrote:
You mentioned that OpenSSL is holding a "snapshot" lock in rand_win.c.
I couldn't find anything like that in that file. Can you specifically
point me to the code that you are referring to? I would also like to
get an opinion on possible workarounds t
You mentioned that OpenSSL is holding a "snapshot" lock in rand_win.c. I
couldn't find anything like that in that file. Can you specifically point
me to the code that you are referring to? I would also like to get an
opinion on possible workarounds that I can enforce to avoid the deadlock.
1. Can
From the evidence given, I would *almost* certainly characterize
this as a deadlock bug in ntdll.dll, the deepest, most trusted
user mode component of Windows!
Specifically, nothing should allow regular user code such as
OpenSSL to hold onto NT internal critical sections while not
running inside
Hi,
OpenSSL Version: 0.9.8o
OS : Windows Server 2008 R2 SP1
I am seeing a deadlock in a windows application between two threads, one
thread calling Heap32First from OpenSSL's RAND_poll and the other that
allocates memory over the heap.
Here is the relevant stack trace from both the threads invol
16 matches
Mail list logo
