青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

在前面C++中基于Crt的內(nèi)存泄漏檢測一文中提到的方法已經(jīng)可以解決我們的大部分內(nèi)存泄露問題了,但是該方法是有前提的,那就是一定要有源代碼,而且還只能是Debug版本調(diào)試模式下。實際上很多時候我們的程序會用到第三方?jīng)]有源代碼的模塊,有些情況下我們甚至懷疑系統(tǒng)模塊有內(nèi)存泄露,但是有沒有證據(jù),我們該怎么辦? 這時我們就要依靠無所不能的WinDbg了。

WinDbg的!heap命令非常強大,結(jié)合AppVerifier可以對堆(heap)內(nèi)存進行詳細的跟蹤和分析, 我們接下來對下面的代碼進行內(nèi)存泄漏的分析:
// MemLeakTest.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include <Windows.h>
#include <stdio.h>

int _tmain(int argc, _TCHAR* argv[])
{
    char* p1 = new char;
    printf("%p\n", p1);

    char* pLargeMem = new char[40000];

    for(int i=0; i<1000; ++i)
    {
        char* p = new char[20];
    }
    
    system("pause");

    return 0;
}

首先下載安裝AppVerifier, 可到這里下載, 把我們需要測試的程序添加到AppVerifier的檢測列表中, 然后保存。

注: 我們這里用AppVerifier主要是為了打開頁堆(page heap)調(diào)試功能,你也可以用系統(tǒng)工具 gflags.exe 來做同樣的事。 

雙擊運行我們要調(diào)試的MemLeakTest.exe, 效果如下:


然后將WinDbg Attach上去, 輸入命令 !heap -p -a 0x02FC1FF8,結(jié)果如下:
0:001> !heap -p -a 0x02FC1FF8
    address 02fc1ff8 found in
    _DPH_HEAP_ROOT @ 2f01000
    in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
                                 2f02548:          2fc1ff8                1 -          2fc1000             2000
    5a8c8e89 verifier!AVrfDebugPageHeapAllocate+0x00000229
    77485c4e ntdll!RtlDebugAllocateHeap+0x00000030
    77447e5e ntdll!RtlpAllocateHeap+0x000000c4
    774134df ntdll!RtlAllocateHeap+0x0000023a
    5b06a65d vrfcore!VfCoreRtlAllocateHeap+0x00000016
    5a92f9ea vfbasics!AVrfpRtlAllocateHeap+0x000000e2
    72893db8 MSVCR90!malloc+0x00000079
    72893eb8 MSVCR90!operator new+0x0000001f
    012c1008 MemLeakTest!wmain+0x00000008 [f:\test\memleaktest\memleaktest\memleaktest.cpp @ 11]
    77331114 kernel32!BaseThreadInitThunk+0x0000000e
    7741b429 ntdll!__RtlUserThreadStart+0x00000070
    7741b3fc ntdll!_RtlUserThreadStart+0x0000001b

怎么樣, 神奇吧?我們當(dāng)分配該地址內(nèi)存時的堆棧(stack)被完整地打印了出來。

當(dāng)然有人很快會說:這是你知道內(nèi)存地址的情況, 很多情況下我們是不知道該地址的,該如何分析?

對于這種情況, 我們首先需要明確一些概念, 我們new出來的內(nèi)存是分配在堆上, 那一個進程里究竟有多少個堆, 每個模塊都有自己單獨的堆嗎?實際上一個進程可以有任意多個堆,我們可以通過CreateHeap創(chuàng)建自己單獨的堆, 然后通過HeapAlloc分配內(nèi)存。 我們new出來的內(nèi)存是crt(C運行庫)分配的, 那就涉及到crt究竟有多少個堆了? crt有多少個堆由你編譯每個模塊(Dll/Exe)時的編譯選項決定, 如果你運行庫選項用的是/MD, 那就和其他模塊共享一個堆; 如果用/MT, 那就是自己單獨的堆。大部分情況下我們會用/MD,這樣我們在一個模塊里new內(nèi)存, 另一個模塊里delete不會有問題, 因為大家共享一個堆。

明確這些概念之后, 我們看看我們的測試程序有多少個堆, 輸入!heap -p
0:001> !heap -p

    Active GlobalFlag bits:
        vrf - Enable application verifier
        hpa - Place heap allocations at ends of pages

    StackTraceDataBase @ 00160000 of size 01000000 with 00000034 traces

    PageHeap enabled with options:
        ENABLE_PAGE_HEAP
        COLLECT_STACK_TRACES

    active heaps:

    + 1160000
        ENABLE_PAGE_HEAP COLLECT_STACK_TRACES 
      NormalHeap - 1300000
          HEAP_GROWABLE 
    + 1400000
        ENABLE_PAGE_HEAP COLLECT_STACK_TRACES 
      NormalHeap - 16b0000
          HEAP_GROWABLE HEAP_CLASS_1 
    + 2360000
        ENABLE_PAGE_HEAP COLLECT_STACK_TRACES 
      NormalHeap - 1280000
          HEAP_GROWABLE HEAP_CLASS_1 
    + 2f00000
        ENABLE_PAGE_HEAP COLLECT_STACK_TRACES 
      NormalHeap - 31d0000
          HEAP_GROWABLE HEAP_CLASS_1 
可以看到我們的測試程序一共有4 個堆。

接下來我們的問題就是確定哪個是我們的crt堆, 也就是我們需要分析每個堆創(chuàng)建時的堆棧(stack)情況.

我們接下來分析最后一個堆, handle是2f00000, 輸入!heap -p -h 02f00000 分析該堆的內(nèi)存分配情況
0:001> !heap -p -h 02f00000
    _DPH_HEAP_ROOT @ 2f01000
    Freed and decommitted blocks
      DPH_HEAP_BLOCK : VirtAddr VirtSize
        02f01f04 : 02f09000 00002000
        02f02e38 : 02f69000 00002000
        037e2548 : 03892000 00002000
        037e2514 : 03894000 00002000
    Busy allocations
      DPH_HEAP_BLOCK : UserAddr  UserSize - VirtAddr VirtSize
        02f01f6c : 02f05de8 00000214 - 02f05000 00002000
        02f01f38 : 02f07800 00000800 - 02f07000 00002000
        02f01ed0 : 02f0bde0 00000220 - 02f0b000 00002000
        02f01e9c : 02f0df50 000000ac - 02f0d000 00002000
        02f01e68 : 02f0ffe0 0000001f - 02f0f000 00002000
        02f01e34 : 02f11fd8 00000028 - 02f11000 00002000
        02f01e00 : 02f13fe0 0000001d - 02f13000 00002000
        02f01dcc : 02f15fc0 0000003a - 02f15000 00002000
        ....

可以看到該堆 _DPH_HEAP_ROOT 結(jié)構(gòu)的地址是 2f01000,通過dt命令打印該結(jié)構(gòu)地址
0:001> dt ntdll!_DPH_HEAP_ROOT CreateStackTrace 2f01000
   +0x0b8 CreateStackTrace : 0x0017cbe4 _RTL_TRACE_BLOCK

可以看到StackTrace的地址是 0x0017cbe4, 通過dds命令打印該地址內(nèi)的符號
0:001> dds 0x0017cbe4 
0017cbe4  00178714
0017cbe8  00007001
0017cbec  000f0000
0017cbf0  5a8c8969 verifier!AVrfDebugPageHeapCreate+0x439
0017cbf4  7743a9e8 ntdll!RtlCreateHeap+0x41
0017cbf8  5a930109 vfbasics!AVrfpRtlCreateHeap+0x56
0017cbfc  755fdda2 KERNELBASE!HeapCreate+0x55
0017cc00  72893a4a MSVCR90!_heap_init+0x1b
0017cc04  72852bb4 MSVCR90!__p__tzname+0x2a
0017cc08  72852d5e MSVCR90!_CRTDLL_INIT+0x1e
0017cc0c  5a8dc66d verifier!AVrfpStandardDllEntryPointRoutine+0x99
0017cc10  5b069164 vrfcore!VfCoreStandardDllEntryPointRoutine+0x121
0017cc14  5a92689c vfbasics!AVrfpStandardDllEntryPointRoutine+0x9f
0017cc18  7741af58 ntdll!LdrpCallInitRoutine+0x14
0017cc1c  7741fd6f ntdll!LdrpRunInitializeRoutines+0x26f
0017cc20  774290c6 ntdll!LdrpInitializeProcess+0x137e
0017cc24  77428fc8 ntdll!_LdrpInitialize+0x78
0017cc28  7741b2f9 ntdll!LdrInitializeThunk+0x10
0017cc2c  00000000
0017cc30  00009001

現(xiàn)在我們可以看到該堆被Create時的完整堆棧了, 通過堆棧,我們可以看到該堆正是由crt創(chuàng)建的, 也就是說我們new的內(nèi)存都分配在該堆內(nèi)。

如果你覺得上面跟蹤堆創(chuàng)建的過程太復(fù)雜,可以先忽略, 下面我們分析堆狀態(tài), 輸入!heap -stat -h 0,它會分析所有堆的當(dāng)前使用狀態(tài), 我們著重關(guān)注我們的crt堆02f00000:
Allocations statistics for
 heap @ 02f00000
group-by: TOTSIZE max-display: 20
    size     #blocks     total     ( %) (percent of total busy bytes)
    9c40 1 - 9c40  (52.66)
    14 3ea - 4e48  (26.38)
    1000 1 - 1000  (5.39)
    800 2 - 1000  (5.39)
    490 1 - 490  (1.54)
    248 1 - 248  (0.77)
    220 1 - 220  (0.72)
    214 1 - 214  (0.70)
    ac 2 - 158  (0.45)
    82 2 - 104  (0.34)
    6a 2 - d4  (0.28)
    50 2 - a0  (0.21)
    28 4 - a0  (0.21)
    98 1 - 98  (0.20)
    94 1 - 94  (0.19)
    8a 1 - 8a  (0.18)
    2e 3 - 8a  (0.18)
    41 2 - 82  (0.17)
    80 1 - 80  (0.17)
    7c 1 - 7c  (0.16)

我們可以看到排在第一位的是大小為0x9c40 (0n40000)的內(nèi)存,分配了1次, 第二位的是大小為 0x14 (0n20) 的內(nèi)存,分配了3ea (0n1002)次.
 回頭再看我們的測試程序,怎么樣? 是不是感覺很熟悉了。

輸入!heap -flt s 0x9c40, 讓W(xué)inDbg列出所有大小為0x9c40的內(nèi)存:
0:001> !heap -flt s 0x9c40
    _DPH_HEAP_ROOT @ 1161000
    Freed and decommitted blocks
      DPH_HEAP_BLOCK : VirtAddr VirtSize
    Busy allocations
      DPH_HEAP_BLOCK : UserAddr  UserSize - VirtAddr VirtSize
    _HEAP @ 1300000
    _DPH_HEAP_ROOT @ 1401000
    Freed and decommitted blocks
      DPH_HEAP_BLOCK : VirtAddr VirtSize
    Busy allocations
      DPH_HEAP_BLOCK : UserAddr  UserSize - VirtAddr VirtSize
    _HEAP @ 16b0000
    _DPH_HEAP_ROOT @ 2361000
    Freed and decommitted blocks
      DPH_HEAP_BLOCK : VirtAddr VirtSize
    Busy allocations
      DPH_HEAP_BLOCK : UserAddr  UserSize - VirtAddr VirtSize
    _HEAP @ 1280000
    _DPH_HEAP_ROOT @ 2f01000
    Freed and decommitted blocks
      DPH_HEAP_BLOCK : VirtAddr VirtSize
    Busy allocations
      DPH_HEAP_BLOCK : UserAddr  UserSize - VirtAddr VirtSize
        02f024e0 : 02fc63c0 00009c40 - 02fc6000 0000b000
    _HEAP @ 31d0000

可以看到, WinDbg幫我們找到了一個符合要求的分配, 它的UserAddr是02fc63c0, 該地址實際上就是代碼char* pLargeMem = new char[40000]分配的地址, 按照開頭的方法, 輸入!heap -p -a 02fc63c0 
0:001> !heap -p -a 02fc63c0
    address 02fc63c0 found in
    _DPH_HEAP_ROOT @ 2f01000
    in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
                                 2f024e0:          2fc63c0             9c40 -          2fc6000             b000
    5a8c8e89 verifier!AVrfDebugPageHeapAllocate+0x00000229
    77485c4e ntdll!RtlDebugAllocateHeap+0x00000030
    77447e5e ntdll!RtlpAllocateHeap+0x000000c4
    774134df ntdll!RtlAllocateHeap+0x0000023a
    5b06a65d vrfcore!VfCoreRtlAllocateHeap+0x00000016
    5a92f9ea vfbasics!AVrfpRtlAllocateHeap+0x000000e2
    72893db8 MSVCR90!malloc+0x00000079
    72893eb8 MSVCR90!operator new+0x0000001f
    012c101e MemLeakTest!wmain+0x0000001e [f:\test\memleaktest\memleaktest\memleaktest.cpp @ 13]
    77331114 kernel32!BaseThreadInitThunk+0x0000000e
    7741b429 ntdll!__RtlUserThreadStart+0x00000070
    7741b3fc ntdll!_RtlUserThreadStart+0x0000001b

可以看到該堆棧就是我們
new char[40000]的堆棧, 用同樣的方法, 我們可以分析出上面代碼for循環(huán)中的1000次內(nèi)存泄漏。

最后, 總結(jié)一下, 通過WinDbg結(jié)合AppVerifier, 我們可以詳細的跟蹤堆中new出來的每一塊內(nèi)存。 很多時候在沒有源代碼的Release版本中,在程序運行一段時間后,如果我們發(fā)現(xiàn)有大塊內(nèi)存或是大量同樣大小的小內(nèi)存一直沒有釋放,  我們就可以用上面的方法進行分析。有些情況下,我們甚至可以將 _CrtDumpMemoryLeaks()和WinDbg的!heap -p -a [address]命令結(jié)合起來使用, 由前者打印泄漏地址,后者分析調(diào)用堆棧,以便快速的定位問題。

posted on 2013-02-27 14:35 Richard Wei 閱讀(19008) 評論(10)  編輯 收藏 引用 所屬分類: windbg

FeedBack:
# re: 基于WinDbg的內(nèi)存泄漏分析[未登錄]
2013-02-27 17:22 | Hunter
文章非常精彩,收藏了,謝謝博主。
我有一個問題,如何顯示012c101e MemLeakTest!wmain+0x0000001e [f:\test\memleaktest\memleaktest\memleaktest.cpp @ 13],
我的Windbg只顯示003e101f MemLeakTest!wmain+0x0000001f,再次感謝。  回復(fù)  更多評論
  
# re: 基于WinDbg的內(nèi)存泄漏分析
2013-02-27 17:30 | Richard Wei
@Hunter
需要memleaktest.exe的pdb符號文件,我用Vs2008, release版也會默認(rèn)生成,如果沒有生成就要在編譯選項里設(shè)置了。  回復(fù)  更多評論
  
# re: 基于WinDbg的內(nèi)存泄漏分析
2013-03-01 09:28 | zuhd
高手都放棄OD了 都用windbg
為啥我總落伍啊  回復(fù)  更多評論
  
# re: 基于WinDbg的內(nèi)存泄漏分析
2013-03-01 20:08 | Richard Wei
@zuhd
懂得程序運行的原理是關(guān)鍵, 工具都差不多, 用GCC和VC一樣可以寫C++代碼。  回復(fù)  更多評論
  
# re: 基于WinDbg的內(nèi)存泄漏分析
2014-01-23 13:56 | jenics
博主你好,為什么我只到這里。。
address 033e4ff8 found in
_DPH_HEAP_ROOT @ 3231000
in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize)
3233924: 33e4ff8 1 - 33e4000 2000
6d4c8e89 verifier!AVrfDebugPageHeapAllocate+0x00000229
77665ede ntdll!RtlDebugAllocateHeap+0x00000030
7762a40a ntdll!RtlpAllocateHeap+0x000000c4
775f5ae0 ntdll!RtlAllocateHeap+0x0000023a
6da61504 vfbasics!AVrfpRtlAllocateHeap+0x000000c3

下面的都沒有呢?  回復(fù)  更多評論
  
# re: 基于WinDbg的內(nèi)存泄漏分析
2014-02-08 12:22 | Richard Wei
@jenics
是不是因為你的程序是沒有PDB文件的Release版  回復(fù)  更多評論
  
# re: 基于WinDbg的內(nèi)存泄漏分析
2014-06-20 18:09 | yuki_apple_baimatan
@ Hunter
用命令 lsa MemLeakTest!wmain+0x0000001f就可以定位到源碼。要事先將源碼的路徑加到windbg中。  回復(fù)  更多評論
  
# re: 基于WinDbg的內(nèi)存泄漏分析
2015-01-12 13:52 | lchen
輸入!heap -stat -h 0,它會分析所有堆的當(dāng)前使用狀態(tài), 我們著重關(guān)注我們的crt堆02f00000

想請教下:程序不只一個堆,從哪里看出只要關(guān)注02f00000這個堆呢?  回復(fù)  更多評論
  
# re: 基于WinDbg的內(nèi)存泄漏分析
2015-01-12 13:52 | lchen
輸入!heap -stat -h 0,它會分析所有堆的當(dāng)前使用狀態(tài), 我們著重關(guān)注我們的crt堆02f00000

想請教下:程序不只一個堆,從哪里看出只要關(guān)注02f00000這個堆呢?  回復(fù)  更多評論
  
# re: 基于WinDbg的內(nèi)存泄漏分析
2015-01-12 16:38 | Richard Wei
@lchen
這個沒啥好方法, 感覺只能通過查看每個堆建立時的堆棧情況來判斷  回復(fù)  更多評論
  
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            一区二区久久| 欧美日韩精品二区第二页| 久久综合五月| 久久国产视频网站| 久久久久久九九九九| 久久另类ts人妖一区二区| 久久亚洲欧美国产精品乐播| 久久在线免费观看| 美女网站在线免费欧美精品| 欧美粗暴jizz性欧美20| 亚洲高清精品中出| 亚洲日本欧美| 中文成人激情娱乐网| 午夜精品久久久久久久蜜桃app| 久久综合导航| 亚洲欧洲精品成人久久奇米网| 亚洲精品一区二区三区在线观看| 亚洲视频第一页| 久久精品亚洲乱码伦伦中文| 免费在线看成人av| 欧美系列一区| 在线日韩成人| 欧美午夜精品久久久久久孕妇 | 国内成人在线| 亚洲乱码视频| 欧美一级夜夜爽| 欧美电影专区| 亚洲欧美在线一区| 欧美理论电影在线播放| 国产欧美一区二区三区在线老狼 | 久久久久天天天天| 欧美日本国产视频| 狠狠色丁香婷婷综合| 99国产精品自拍| 美女精品国产| 一区二区三区四区在线| 久久香蕉国产线看观看网| 欧美日韩精品一区二区在线播放 | 91久久精品日日躁夜夜躁欧美 | 欧美日韩日日骚| 在线观看日韩av| 校园激情久久| 日韩视频永久免费观看| 美女成人午夜| 揄拍成人国产精品视频| 欧美专区亚洲专区| 亚洲影视在线| 国产精品大片免费观看| 亚洲日本国产| 欧美大学生性色视频| 久久av在线看| 国产一区91精品张津瑜| 亚洲欧美日韩精品久久亚洲区 | 国产又爽又黄的激情精品视频| 亚洲婷婷国产精品电影人久久| 欧美国产第一页| 另类欧美日韩国产在线| 在线观看成人小视频| 久久九九全国免费精品观看| 午夜精品久久久久久久99樱桃| 欧美香蕉大胸在线视频观看| 亚洲天堂网站在线观看视频| 一本一本久久a久久精品牛牛影视| 欧美激情一区二区三区四区| 亚洲日本免费| 日韩亚洲欧美综合| 国产精品成人免费| 欧美在线黄色| 国产欧美日韩亚洲精品| 欧美一区二区三区的| 亚洲欧美日韩国产综合在线| 国产伦精品一区二区三区高清| 亚洲欧美在线网| 午夜国产精品视频| 狠狠色丁香久久婷婷综合丁香| 美女精品视频一区| 欧美精品videossex性护士| 这里只有精品丝袜| 亚洲欧美一区二区三区极速播放 | 日韩一级精品| 亚洲网在线观看| 国产一区二区日韩精品| 欧美+日本+国产+在线a∨观看| 鲁鲁狠狠狠7777一区二区| 亚洲精品综合久久中文字幕| 一区二区三区日韩在线观看| 国产日韩欧美麻豆| 欧美黄色小视频| 国产精品xxxxx| 老司机免费视频一区二区| 欧美国产极速在线| 欧美一级视频精品观看| 麻豆精品视频| 午夜精品偷拍| 噜噜爱69成人精品| 亚洲欧美在线免费| 欧美99在线视频观看| 午夜免费在线观看精品视频| 久久综合久色欧美综合狠狠| 亚洲午夜女主播在线直播| 久久精品视频在线| 亚洲在线不卡| 免费在线播放第一区高清av| 欧美影院一区| 欧美日韩精品免费观看视频完整| 久久成人这里只有精品| 欧美激情视频给我| 久久久久亚洲综合| 国产精品播放| 欧美体内谢she精2性欧美| 老司机一区二区| 国产精品亚洲综合色区韩国| 亚洲国产一区二区三区在线播| 国产精品影音先锋| 亚洲精品中文字幕在线| 亚洲大胆女人| 久久国产精品第一页 | 欧美黄色视屏| 国产在线麻豆精品观看| 亚洲视频香蕉人妖| 99国产精品久久久久老师| 久久久噜噜噜久久中文字免| 久久99伊人| 国产欧美欧洲在线观看| 夜夜狂射影院欧美极品| 久久欧美肥婆一二区| 亚洲欧美综合国产精品一区| 欧美国产日韩视频| 亚洲第一主播视频| 1000部精品久久久久久久久| 亚洲黄色视屏| 国产一区二区三区自拍| 欧美精品一区二区在线播放| 久久综合狠狠综合久久激情| 久久亚洲精品一区| 免费中文字幕日韩欧美| 猫咪成人在线观看| 欧美日韩伦理在线免费| 国产精品欧美在线| 影音国产精品| 亚洲综合国产| 欧美激情无毛| 在线视频精品一| 老巨人导航500精品| 欧美日韩免费观看一区二区三区| 国产精品青草久久久久福利99| 黄色小说综合网站| 夜夜狂射影院欧美极品| 久久激情一区| av成人天堂| 欧美成人国产| 亚洲欧洲精品一区| 久久久久久亚洲精品中文字幕| 亚洲美洲欧洲综合国产一区| 久久网站热最新地址| 欧美激情国产日韩精品一区18| 国产精品久久婷婷六月丁香| 亚洲国产裸拍裸体视频在线观看乱了| 这里只有视频精品| 亚洲黄色成人网| 欧美黄色aaaa| 亚洲国产成人高清精品| 久久亚洲国产精品日日av夜夜| 中国av一区| 国产精品v欧美精品v日韩精品| 亚洲国产免费看| 免费在线观看一区二区| 久久成人综合视频| 在线精品视频一区二区三四| 欧美午夜免费影院| 亚洲免费成人| 99re热精品| 国产模特精品视频久久久久| 久久久免费精品| 老司机免费视频一区二区| 亚洲国产人成综合网站| 亚洲大胆人体视频| 欧美日韩亚洲91| 久久高清一区| 欧美不卡在线| 性视频1819p久久| 久久狠狠久久综合桃花| 亚洲日本成人网| 亚洲一区二区免费看| 在线观看视频日韩| 99热这里只有精品8| 亚洲国产1区| 亚洲欧美综合精品久久成人| 欧美日韩国产在线看| 蜜臀av在线播放一区二区三区 | 一本色道久久99精品综合| 国产亚洲精品bt天堂精选| 亚洲国产一区二区a毛片| 国产色产综合产在线视频| 亚洲欧洲精品一区二区三区| 极品少妇一区二区三区| 欧美一区三区三区高中清蜜桃 | 欧美sm视频| 久久久蜜桃精品| 国产欧美在线|